【GitOps系列】监听镜像版本变化触发 GitOps工作流

前言

在【GitOps系列】使用 ArgoCD 快速打造GitOps工作流 博文中，我们创建的 GitOps 工作流有下面两个重要的特点：

1. 源码和 Helm Chart 在同一个仓库下
2. 在 CI 阶段更新了 Helm Chart 镜像版本

在开发和发布分工明确的团队中，更推荐将源码和应用定义分离，考虑到安全性和发布的严谨性，也尽量不要通过 CI 直接修改应用定义。

更合理的研发规范设计应该是这样的：

开发负责编写代码，并通过 CI 生成制品（Docker 镜像），并对生成的制品负责。而SRE 团队则对应用定义负责。在发布环节， 开发可以随时控制要发布的镜像版本，而无需关注其他的应用细节，他们之间的工作流程图如下：

以上工作流程图我们可以看出，开发和 SRE 团队各司其职，只操作和自己相关的 Git 仓库，互不干扰。但 SRE 团队要怎么知道开发团队什么时候发布以及发布什么版本的镜像呢？
最原始的办法是：开发在需要发布的时候将镜像版本告诉 SRE 团队，SRE 团队手动修改 Helm Chart 镜像版本并推送到 Git 仓库，等待 ArgoCD 同步完成。
这种办法虽然有效，但沟通效率低且容易出错， 我们需要一种自动化的机制来替代这个过程。
那就是借助 ArgoCD Image Updater，我们可以让 ArgoCD 自动监控镜像仓库的更新情况，一旦工作负载中的镜像版本有更新，ArgoCD 就会自动将工作负载升级为新的镜像版本，并且还可以自动将镜像的版本号回写到 Helm Chart 仓库中，保持应用定义和集群状态的一致性。

工作流总览

最终要期望实现的效果如下：

1. 将一个 Git 仓库拆分成了两个，一个存放源码，一个存放 Helm Chart；
2. 不再使用 CI 更新 Helm Chart 镜像版本，而是使用 ArgoCD Image Updater 来自动监控镜像仓库的变更。

此外，由于在日常开发中，我们一般会采用多分支进行开发，这就随时可能产生新的镜像版本。为了将开发过程和需要发布到生产环境的镜像区分开，我们会为 Main 分支构建出来的镜像增加一个 Prefix 标识，例如 main-${commit_Id}，并配置 ArgoCD Image Updater 只监控包含特定标识的镜像版本。
最终实现的效果是：
当开发将代码提交到 Git 仓库 Main 分支后，将触发自动构建，并将新的镜像版本推送到镜像仓库。ArgoCD Image Updater 会以 Poll 的方式每 2 分钟检查一次工作负载的镜像是否有新的版本，如果有，那么就将工作负载的镜像更新为最新版本，并将镜像版本号写入同步到存放 Helm Chart 的仓库中。

安装和配置 ArgoCD Image Updater

注： 前提需要安装好ArgoCD ~~~
~# kubectl apply -n argocd -f https://ghproxy.com/https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml

创建 Image Pull Secret（可选）

由于 ArgoCD 会主动 Poll 镜像仓库来检查是否存在新版本，如果你使用的是私有镜像仓库，那么你需要创建 Secret 对象，以便为 ArgoCD 提供访问镜像仓库的权限。
以 DockerHub 仓库为例，执行下面的命令来创建 Secret 对象:

$ kubectl