文章目录
- 前言
- 工作流总览
- 安装和配置 ArgoCD Image Updater
- 创建 Image Pull Secret(可选)
- 创建 Helm Chart 仓库
- 创建 ArgoCD Application
- 删除旧应用(可选)
- 配置仓库访问权限
- 创建 ArgoCD 应用
- 体验 GitOps 工作流
- 总结
前言
在【GitOps系列】使用 ArgoCD 快速打造GitOps工作流 博文中,我们创建的 GitOps 工作流有下面两个重要的特点:
- 源码和 Helm Chart 在同一个仓库下
- 在 CI 阶段更新了 Helm Chart 镜像版本
在开发和发布分工明确的团队中,更推荐将源码和应用定义分离,考虑到安全性和发布的严谨性,也尽量不要通过 CI 直接修改应用定义。
更合理的研发规范设计应该是这样的:
开发负责编写代码,并通过 CI 生成制品(Docker 镜像),并对生成的制品负责。而SRE 团队则对应用定义负责。在发布环节, 开发可以随时控制要发布的镜像版本,而无需关注其他的应用细节,他们之间的工作流程图如下:
以上工作流程图我们可以看出,开发和 SRE 团队各司其职,只操作和自己相关的 Git 仓库,互不干扰。但 SRE 团队要怎么知道开发团队什么时候发布以及发布什么版本的镜像呢?
最原始的办法是:开发在需要发布的时候将镜像版本告诉 SRE 团队,SRE 团队手动修改 Helm Chart 镜像版本并推送到 Git 仓库,等待 ArgoCD 同步完成。
这种办法虽然有效,但沟通效率低且容易出错, 我们需要一种自动化的机制来替代这个过程。
那就是借助ArgoCD Image Updater
,我们可以让 ArgoCD 自动监控镜像仓库的更新情况,一旦工作负载中的镜像版本有更新,ArgoCD 就会自动将工作负载升级为新的镜像版本,并且还可以自动将镜像的版本号回写到 Helm Chart 仓库中,保持应用定义和集群状态的一致性。
工作流总览
最终要期望实现的效果如下:
- 将一个 Git 仓库拆分成了两个,一个存放源码,一个存放 Helm Chart;
- 不再使用 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 create -n argocd secret docker-registry dockerhub-secret \--docker-username $DOCKER_USERNAME \--docker-password $DOCKER_PERSONAL_TOKEN \--docker-server "https://registry-1.docker.io"secret/dockerhub-secret created
创建 Helm Chart 仓库
$ cp -r ./kubernetes-example/helm ./kubernetes-example-helm$ cd kubernetes-example-helm && git init
PS:前往 GitHub 创建一个新的仓库,将其命名为 kubernetes-example-helm
$ git add .
$ git commit -m "first commit"
$ git branch -M main
$ git remote add origin https://github.com/Hugh-yw/kubernetes-example-helm.git
$ git push -u origin main
创建 ArgoCD Application
删除旧应用(可选)
清理之前实践的应用!!!
$ argocd app delete example --cascade
配置仓库访问权限
创建 ArgoCD 应用时,必须要配置仓库访问权限,但这里额外还实现了一个重要的功能:为 ArgoCD Image Updater 提供回写
kubernetes-example-helm
仓库的权限。
$ argocd repo add https://github.com/Hugh-yw/kubernetes-example-helm.git --username $USERNAME --password $PASSWORD~# argocd repo list
TYPE NAME REPO INSECURE OCI LFS CREDS STATUS MESSAGE PROJECT
git https://github.com/Hugh-yw/kubernetes-example-helm.git false false false true Successful
git https://github.com/Hugh-yw/kubernetes-example.git false false false true Successful
创建 ArgoCD 应用
通过YAML创建:
# cat application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:name: exampleannotations:argocd-image-updater.argoproj.io/backend.allow-tags: regexp:^mainargocd-image-updater.argoproj.io/backend.helm.image-name: backend.imageargocd-image-updater.argoproj.io/backend.helm.image-tag: backend.tagargocd-image-updater.argoproj.io/backend.pull-secret: pullsecret:argocd/dockerhub-secretargocd-image-updater.argoproj.io/frontend.allow-tags: regexp:^mainargocd-image-updater.argoproj.io/frontend.helm.image-name: frontend.imageargocd-image-updater.argoproj.io/frontend.helm.image-tag: frontend.tagargocd-image-updater.argoproj.io/frontend.pull-secret: pullsecret:argocd/dockerhub-secretargocd-image-updater.argoproj.io/image-list: frontend=cyw/frontend, backend=cyw/backendargocd-image-updater.argoproj.io/update-strategy: latestargocd-image-updater.argoproj.io/write-back-method: git
spec:destination:namespace: gitops-example-updaterserver: https://kubernetes.default.svcproject: defaultsource:path: .repoURL: https://github.com/Hugh-yw/kubernetes-example-helm.gittargetRevision: mainsyncPolicy:automated: {}syncOptions:- CreateNamespace=true$ kubectl create -f application.yaml -n argocd
PS:效果等同于使用 argocd app create 命令
ArgoCD Image Updater 通过 Application Annotations 标签来实现对应的功能,简单介绍下每一个标签的作用:
- argocd-image-updater.argoproj.io/image-list:指定需要监听的镜像,这里我们指定示例应用的前后端镜像 cyw/frontend 和 cyw/backend,同时为前后端镜像法指定了别名,分别为 frontend 和 backend。这里的别名非常重要,会影响下面所有的设置。
- argocd-image-updater.argoproj.io/update-strategy:指定镜像更新策略。注意, latest 并不代表监听 latest 镜像版本,而是以最新推送的镜像作为更新策略。此外,semver 策略可以识别最高语义化版本的标签,digest 策略可以用来区分同一 Tag 下不同镜像 digest 的变更。
- argocd-image-updater.argoproj.io/write-back-method:表示将镜像版本回写到镜像仓库。注意,这里对仓库的写权限来源于使用 argocd repo add 命令为 ArgoCD 配置的仓库访问权限。
- argocd-image-updater.argoproj.io/<镜像别名>.pull-secret:为不同的镜像别名指定镜像拉取凭据。
- argocd-image-updater.argoproj.io/<镜像别名>.allow-tags:配置符合更新条件的镜像 Tag,在这里我们使用正则表达式匹配那些镜像 Tag 以 main 开头的镜像版本,其他镜像版本则忽略。
- argocd-image-updater.argoproj.io/<镜像别名>.helm.image-name:配置 Helm Chart values.yaml 镜像名称所在的节点,在示例应用中,backend.image 和 frontend.image 是values.yaml 配置镜像名称的节点,ArgoCD 在回写仓库时会覆盖这个值。
- argocd-image-updater.argoproj.io/<镜像别名>.helm.image-tag:配置 Helm Chart values.yaml 镜像版本所在的节点,在示例应用中,backend.tag 和 frontend.tag 是 values.yaml 配置镜像版本的节点,ArgoCD 在回写仓库时将会覆盖这个值。
体验 GitOps 工作流
作为开发同学,尝试修改 frontend/src/App.js 源代码文件,例如修改文件第 49 行的“Hi! I am a geekbang”内容。修改完成后, 将代码推送到 GitHub 的 main 分支 merge。
此时会触发两个 GitHub Action 工作流。其中,当 build-every-branch 工作流被触发时,它将构建 Tag 为 main 开头的镜像版本,并将其推送到镜像仓库中,如下图所示:
跟另一个 GitHub Action 工作流不同的是:
它也不会去主动修改 kubernetes-example-helm 仓库的 values.yaml 文件,在完成镜像推送后工作流也就结束了。
与此同时,ArgoCD Image Updater 将会每 2 分钟从镜像仓库检索 frontend 和 backend 的镜像版本,一旦发现有新的并且以 main 开头的镜像版本,它将自动使用新版本来更新集群内工作负载的镜像,并将镜像版本回写到 kubernetes-example-helm 仓库。
在回写时,ArgoCD Image Updater 并不会直接修改仓库的 values.yaml 文件,而是会创建一个专门用于覆盖 Helm Chart values.yaml 的.argocd-source-example.yaml
文件。
当我们看到这个文件时,说明 ArgoCD Image Updater 已经触发了镜像更新,并且成功将镜像版本回写到了镜像仓库。同时,这个文件记录了详细的覆盖 values.yaml 值的策略。
这样,当 ArgoCD 在做自动同步时,会将这份文件的内容覆盖 values.yaml 对应的值,比如 frontend.tag 的值会被覆盖为main-e1f492f
,这样,回写后的 Helm Chart 和集群内资源对象就仍然能够保持一致性。
至此,我们就完成了通过监听新镜像版本来触发 GitOps 工作流的整个过程。
总结
此次实践,我们将应用源码和应用定义(Helm Chart)拆分成了两个仓库,在开发和发布角色相对独立的研发流程下,这种方式既能够保持他们之间职责独立,权责清晰,同时还保留了开发随时发布生产环境的能力,但是希望集成审批流程,有足够权限的人审批通过后再进行发布!
值得注意的是:在实际的业务场景中,研发同学一般会使用多分支的模式来开发。这意味着每个分支的每个提交都会产生新的镜像版本,所以,为了区分开发过程的镜像和需要被发布到生产环境的镜像,在此次实践中约定了以main
开头的镜像版本即为需要发布到生产环境的镜像版本。你可以根据项目的实际情况做调整,例如使用v1.0.0
的版本号来区分,同时更新argocd-image-updater.argoproj.io/<镜像别名>.allow-tags
字段的正则表达式。
总体来说,在这种仓库分离的场景下,要将开发者的提交和发布过程自动化地连接起来,双方需要重点关注生产环境的镜像版本策略,并将它配置到 ArgoCD 应用的 Annotations 注解内,这样便能够让 ArgoCD Image Updater 代替人工来自动监控需要发布到生产环境的image。