云原生架构与 GitOps 实战
王炜
前腾讯云 CODING 架构师
6217 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
云原生架构与 GitOps 实战
15
15
1.0x
00:00/00:00
登录|注册

23|如何监听镜像版本变化触发 GitOps?

你好,我是王炜。
上一节课,我带你学习了如何使用 ArgoCD 来创建生产可用的 GitOps 工作流。值得注意的是,我们创建的 GitOps 工作流有下面两个重要的特点。
源码和 Helm Chart 在同一个仓库下。
在 CI 阶段更新了 Helm Chart 镜像版本。
在开发和发布分工明确的团队中,我更推荐你将源码和应用定义分离,考虑到安全性和发布的严谨性,也尽量不要通过 CI 直接修改应用定义。
更合理的研发规范设计应该是这样的:开发负责编写代码,并通过 CI 生成制品,也就是 Docker 镜像,并对生成的制品负责。而基础架构部门或者 SRE 团队则对应用定义负责。在发布环节,开发可以随时控制要发布的镜像版本,而无需关注其他的应用细节,他们之间的工作流程图如下。
从上面这张工作流程图我们可以看出,开发和 SRE 团队各司其职,只操作和自己相关的 Git 仓库,互不干扰。但 SRE 团队要怎么知道开发团队什么时候发布以及发布什么版本的镜像呢?
最原始的办法是:开发在需要发布的时候将镜像版本告诉 SRE 团队,SRE 团队手动修改 Helm Chart 镜像版本并推送到 Git 仓库,等待 ArgoCD 同步完成。
这种办法虽然有效,但沟通效率低且容易出错,我们需要一种自动化的机制来替代这个过程
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

使用 ArgoCD 和 ArgoCD Image Updater 实现自动化的 GitOps 工作流是本文的主题。文章首先强调了源码和应用定义分离的重要性,以及开发和基础架构团队各自的职责。传统的手动镜像版本更新方式存在的问题,作者提出了使用 ArgoCD Image Updater 自动监控镜像仓库变更的解决方案。详细介绍了安装和配置 ArgoCD Image Updater 的步骤,以及创建 Helm Chart 仓库和配置 ArgoCD Application 的过程。通过实际操作指导,读者了解了如何利用 ArgoCD 和 ArgoCD Image Updater 实现自动化的 GitOps 工作流,提高了工作效率和准确性。文章还提到了体验 GitOps 工作流的过程,以及总结了如何配置 ArgoCD Image Updater 的 update-strategy 的策略。整体而言,本文为读者提供了一个清晰的指南,帮助他们快速了解并实施自动化的 GitOps 工作流。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《云原生架构与 GitOps 实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(14)

  • 最新
  • 精选
  • 农民园丁
    老师,我用的是自建的gitlab和harbor(自签名证书),CI部分没有问题,build了main开头的镜像并推送到了harbor中,但是CD部分不能更新应用,在pod argocd-image-updater中的日志如下: time="2023-02-02T06:11:46Z" level=error msg="Could not get tags from registry: Get \"https://harbor.imustyckz.com/v2/\": x509: certificate signed by unknown authority" alias=frontend application=example image_name=richey/frontend image_tag=95717a65 registry=harbor.imustyckz.com time="2023-02-02T06:11:46Z" level=error msg="Could not get tags from registry: Get \"https://harbor.imustyckz.com/v2/\": x509: certificate signed by unknown authority" alias=backend application=example image_name=richey/backend image_tag=95717a65 registry=harbor.imustyckz.com time="2023-02-02T06:11:46Z" level=info msg="Processing results: applications=1 images_considered=2 images_skipped=0 images_updated=0 errors=2" 看提示是这个pod没有信任自签名证书,搞了2天还不行,请教怎么解决呢?

    作者回复: Harbor 需要通过 Cert-manager 颁发 TLS 证书,如果还是有错误的话,可以在 argocd-image-updater 项目提交一个 issue:https://github.com/argoproj-labs/argocd-image-updater/issues

    2023-02-02归属地:内蒙古
    2
  • m1k3
    argocd-image-updater.argoproj.io/update-strategy:digest 策略可以用来区分同一 Tag 下不同镜像 digest 的变更。

    作者回复: 👍🏻正确!

    2023-01-31归属地:广东
    2
  • 宝仔
    老师你好,这种helm chart gitops 是不是不同的环境的values文件都要存在git仓库里?比方说我预发环境有staging-values.yaml文件,生产有production-values.yaml文件,因为会存在感配置的情况

    作者回复: 每个环境所需要的配置文件是不同的,比如测试环境你可能用集群内的数据库,生产环境用云数据库。 配置文件并不是一定要存放在 Git 仓库中,比如你可以在创建 ArgoCD 应用的时候配置额外的环境参数。 但我建议将不同环境的配置都存储到仓库里,优点有很多,最大的优点是由于 Git 仓库是唯一可信源,所以在未来你要做环境迁移的时候,可以随时拉起一套环境。

    2023-02-02归属地:浙江
    1
  • RRR
    其实 只要能在 CI 阶段修改 GitOps 的那个仓库就行了 我们现在在 Github Action 中做了这一步,在 Docker Image 构建好之后,使用 yq 直接去仓库提 PR,修改 tag verison 即可。 然后交给别人 approval,通过后就部署了。 很完美的 CD 过程。

    作者回复: 👍🏻这个方案也挺不错的,简单直接。

    2023-08-24归属地:新加坡
    2
  • Geek_06ea70
    老师,我镜像版本是用$CI_COMMIT_SHORT_SHA打的,镜像更新策略用的latest,但ArgoCD Image Updater发现最新的镜像是按$CI_COMMIT_SHORT_SHA的ASCII码取的,而不是最后推送到镜像仓库的

    作者回复: Latest 策略会拿最近一次推送到镜像仓库的镜像来进行更新。

    2023-04-18归属地:广东
  • 黄在在同学
    老师您好,通常情况下,我们可能需要对部署结果进行通知,比如通知到钉钉里。我用argocd notifications 做了通知,但是这只知道应用的同步结果,无法做到具体哪个pod 部署结果的通知,可以提供下有什么解决思路吗?

    作者回复: 可以参考这里定制通知模板:https://argocd-notifications.readthedocs.io/en/stable/templates/

    2023-04-15归属地:广东
    2
  • 公众号:程序员大兵
    为什么按专栏的操作部署后,frontend 的Pod数一直在增加呢,增加到了10个pod

    作者回复: 可能是 frontend 的 hpa 表现差异导致的,你可以尝试修改 hpa 对象的阈值或者先临时删除它。

    2023-04-02归属地:北京
  • 黄在在同学
    ArgoCD Image Updater 默认每2分钟检索一次镜像是否需要更新。这个时间可以可以自定义设置吗?或者是否可以改为webhook推送的方式?

    作者回复: 可以自定义镜像拉取的间隔时间,具体方法是为 Argocd image updater 的工作负载添加启动参数 --interval 并指定时间,参考这里:https://github.com/argoproj-labs/argocd-image-updater/blob/master/docs/install/reference.md#flags

    2023-03-22归属地:广东
  • 邵涵
    对于文中的 “ArgoCD Image Updater 会以 Poll 的方式每 2 分钟检查一次工作负载的镜像是否有新的版本,如果有,那么就将工作负载的镜像更新为最新版本,并将镜像版本号写入到存放 Helm Chart 的仓库中。” “当 ArgoCD 在做自动同步时,会将这份文件的内容覆盖 values.yaml 对应的值,比如 frontend.tag 的值会被覆盖为 main-b99bc73,这样,回写后的 Helm Chart 和集群内资源对象就仍然能够保持一致性” 这两部分说明,该怎么理解?是 a. ArgoCD先更新Chart仓库,也就是添加/更新.argocd-source-example.yaml,然后使用Chart原本的所有文件加上这个.argocd-source-example.yaml计算出工作负载对象的预期状态,以此去与k8s集群中的工作负载做对比和更新 还是 b. 先更新k8s集群中的工作负载,然后再更新Chart仓库中的文件 个人理解应该是a,因为ArgoCD应该是对比应用定义和k8s中的工作负载,应用定义的变更可能有多种,不止是镜像版本的自动更新,还可能有其他人工手动做的变更,ArgoCD应该是都能监控、比对、更新。但是,从上边两段描述看,感觉像是b……请您指教

    作者回复: 先更新集群工作负载的镜像版本,再回写。 换个角度,你可以这么考虑,回写仓库是可选的。如果不回写,那么 image updater 为了更新工作负载的镜像,就必须要修改集群内 Manifest image 字段。 这样就清楚了。

    2023-03-21归属地:北京
    2
  • gyl1989113
    问下老师build-every-branch 的触发逻辑写到哪的呢。。build.yaml里没找到呢

    作者回复: 这部分在 argocd-image-updater.yaml 文件下定义了。

    2023-02-14归属地:四川
收起评论
显示
设置
留言
14
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部