7.3 实战演练：监听镜像变更与监听应用定义的双模式工作流打造

1. 引言：两种 GitOps 模式之争

在 GitOps 实践中，有两种主流模式：

1. 监听应用定义（App-of-Apps）：Argo CD 监听 Git 中的应用定义变更，自动同步。
2. 监听镜像变更（Image-based）：Argo CD Image Updater 监听镜像仓库的新 Tag，自动更新 Git 并触发部署。

两种模式各有优劣，本节将通过实战对比，帮你选择最适合的场景。

2. 模式一：监听应用定义（传统 GitOps）

2.1 工作流

开发者提交代码 ↓ CI 构建镜像并推送 (myapp:v1.2.3) ↓ 开发者/CI 修改 Git 中的应用定义 (更新 image.tag) ↓ Argo CD 检测到 Git 变更 ↓ 自动同步到集群

2.2 实现步骤

步骤 1：CI 构建镜像

# .github/workflows/ci.yml-name:Build and Pushrun:|docker build -t myapp:${GITHUB_SHA} . docker push myapp:${GITHUB_SHA}

步骤 2：更新应用定义
有两种方式：

方式 A：CI 自动更新（推荐）

-name:Update Deploymentrun:|git clone https://github.com/org/deploy-repo.git cd deploy-repo # 使用 yq 或 sed 更新 values.yaml yq eval '.image.tag = "${GITHUB_SHA}"' -i apps/myapp/overlays/prod/values.yaml git commit -m "Update myapp to ${GITHUB_SHA}" git push

方式 B：开发者手动更新
开发者收到 CI 构建成功的通知后，手动修改 Git 中的应用定义。

步骤 3：Argo CD 自动同步
Argo CD 检测到 Git 变更，自动同步。

2.3 优缺点

优点：

• 完全符合 GitOps 原则（Git 是唯一事实来源）
• 变更可审计（所有部署都有 Git 提交记录）
• 支持手动审批（PR Review）

缺点：

• 需要 CI 系统有 Git 写权限（安全风险）
• 流程稍显复杂（需要两步：构建 + 更新 Git）

3. 模式二：监听镜像变更（Image-based GitOps）

3.1 工作流

开发者提交代码 ↓ CI 构建镜像并推送 (myapp:v1.2.3) ↓ Argo CD Image Updater 检测到新镜像 ↓ 自动更新 Git 中的应用定义 ↓ Argo CD 检测到 Git 变更 ↓ 自动同步到集群

3.2 实现步骤

步骤 1：安装 Argo CD Image Updater

kubectl apply -n a