网站建设网站排名,前端开发专业,辽宁人工智能建站系统软件,长宁区科技网站建设文章目录 前言工作流总览安装和配置 ArgoCD Image Updater创建 Image Pull Secret#xff08;可选#xff09;创建 Helm Chart 仓库创建 ArgoCD Application删除旧应用#xff08;可选#xff09;配置仓库访问权限创建 ArgoCD 应用 体验 GitOps 工作流总结 前言 在【GitOps… 文章目录 前言工作流总览安装和配置 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.iosecret/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: frontendcyw/frontend, backendcyw/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:- CreateNamespacetrue$ 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。
