CICD 流水线就该这么玩系列之一

今天给大家分享的是 DevOps 世界中非常流行的一个 GitOps 工具 - Argo CD。如果你还不知道什么是 GitOps，欢迎留言告诉我，根据热度，我会再写一篇详细讲解 GitOps 的文章。

由于篇幅较长，同时也为了避免阅读疲劳，我把它拆解成 4 个小节来讲解，这样也能让读者最大化吸收并理解文章内容。为了方便及时收到更新，请关注 DevOpsMe 微信公众号，谢谢！

本小节包括以下这些内容：

• Argo CD 是什么？

• Argo CD 是如何工作的？

Argo CD 是什么？

Argo CD 是一个持续交付（CD）工具，但是目前大部分项目中，已经有 Jenkins、GitLab CICD 等 CD 解决方案，为什么又出来另一个 CD 工具呢？Argo CD 和它们有什么区别呢？Argo CD 是不是有什么特别之处，会取代它们吗？接下来我会一一解答这些疑问。

我们先来看看目前大部分项目中是怎么玩 CICD 的。假设项目采用了微服务架构，所有微服务运行在 Kubernetes 集群中。开发人员往代码库 push 了一个特性或者一个 bug fix，Jenkins 持续集成流水线（CI pipeline）会被自动触发，流水线步骤包括有自动化测试，构建 Docker 镜像和推送到镜像仓库，然后是 CD pipeline，把最新的镜像部署到 Kubernetes 集群中，卖个关子，这一步是如何做的呢？

是的，最常见的方法就是直接更新应用的部署 yaml 文件，然后将它 apply 到 Kubernetes 集群。

今天给大家分享的是 DevOps 世界中非常流行的一个 GitOps 工具 - Argo CD。如果你还不知道什么是 GitOps，欢迎留言告诉我，根据热度，我会再写一篇详细讲解 GitOps 的文章。

由于篇幅较长，同时也为了避免阅读疲劳，我把它拆解成 4 个小节来讲解，这样也能让读者最大化吸收并理解文章内容。为了方便及时收到更新，请关注 DevOpsMe 微信公众号，谢谢！

本小节包括以下这些内容：

• Argo CD 是什么？

• Argo CD 是如何工作的？

Argo CD 是什么？

Argo CD 是一个持续交付（CD）工具，但是目前大部分项目中，已经有 Jenkins、GitLab CICD 等 CD 解决方案，为什么又出来另一个 CD 工具呢？Argo CD 和它们有什么区别呢？Argo CD 是不是有什么特别之处，会取代它们吗？接下来我会一一解答这些疑问。

我们先来看看目前大部分项目中是怎么玩 CICD 的。假设项目采用了微服务架构，所有微服务运行在 Kubernetes 集群中。开发人员往代码库 push 了一个特性或者一个 bug fix，Jenkins 持续集成流水线（CI pipeline）会被自动触发，流水线步骤包括有自动化测试，构建 Docker 镜像和推送到镜像仓库，然后是 CD pipeline，把最新的镜像部署到 Kubernetes 集群中，卖个关子，这一步是如何做的呢？

是的，最常见的方法就是直接更新应用的部署 yaml 文件，然后将它 apply 到 Kubernetes 集群。

调整一下 CICD 流水线图，现在应该是下面这样子的。Jenkins 作为 CICD 服务器起到非常关键的作用，这也是大部分项目实施 CICD 的现状。注意，这里的 CD 是 Continuous Delivery。

但是，你有没有考虑过这些问题呢？

• 必须在 Jenkins 上面安装和设置一些工具，例如 kubectl，helm 等

• 在 Jenkins 上配置 credentials，这些工具才可以访问 Kubernetes 集群

• 如果是EKS，那还得配置 Jenkins credentials 以访问 AWS 云平台

• 因为需要把 Kubernetes cluster credential 提供给外部服务和客户端工具，这就引发了安全问题。尤其是部署多个项目的应用到集群，为了只允许访问特定的 Kubernetes 集群，每个项目有自己的 Kubernetes credentials。更有甚者，如果是很多个集群呢？那这个配置工作就变得繁琐了，安全隐患也更大。

• 最重要的是，Jenkins 执行完 CD 流水线后，部署状态是不可见的。也就是，kubectl apply 之后，Jenkins 是不知道它的执行状态的，资源是否被创建，服务是否更新成功且为健康状态，你只能通过接下来的测试步骤去确认。

所以，CD 这一部分是有提升空间的。这时候，就该 Argo CD 入场了，以上这些痛点，它都有自己的解决方案，让持续交付到 Kubernetes 集群更有效率。Argo CD 就是基于 GitOps 的原则为 Kubernetes 而诞生的。

Argo CD 是如何工作的？

那么 Argo CD 是如何提高 CD 效率的呢？我们换位思考一下，把 kubectl apply 到集群这个步骤反转过来，不再从外面去访问 Kubernetes 集群。以前是在集群外面通过 push 的方式去更新资源，现在是集群中有一个 Argo CD agent，它作为集群的一部分使用拉取（pull）的方式，从 git repo 上面拉取 yaml 文件，然后更新资源。

现在来看看用 Argo CD 替代 Jenkins 后，CD 流水线应该是怎样的。概括起来，有下面这几个步骤。

1. 部署 Argo CD 到 Kubernetes 集群

2. 配置 Argo CD 以监控 Git repository 的更新

3. 如果 Argo CD 监控到有更新，自动拉取这些更新，然后更新到 Kubernetes 集群

这里有个关于 Git repository 的最佳实践。

为什么要把业务代码和 Kubernetes yaml file 单独放在不同的 git 仓库呢？其中一个主要的原因是，配置代码不仅仅有 k8s deployment yaml 文件，还有 ConfigMap，Secret，Service，Ingress 等等其它 Kubernetes 资源，当我们只需要更新这些 yaml 文件时，可以独立于业务代码，不会触发 CI pipeline，因为业务代码本身并没有任何更新。也不需要，在 CI pipeline 中写一些复杂的逻辑去检查有哪些更新。这个配置代码库也被称之为 GitOps Repository。

现在整个 CICD 流水线是下面这样子的。

Argo CD 支持 Kubernetes YAML 文件，Helm Charts，Kustomize(kustomize.io) ，还有其它最终会生成为 YAML 格式的模版文件。

我们最终拥有了单独的CI 流水线和 CD 流水线。一般情况下，CI 流水线由开发者或者 DevOps 负责，CD 流水线由 Ops 或者 DevOps 负责（使用 Argo CD）。这样的好处是，不仅有自动化的 CICD 流水线，还能达到关注点分离的目的，不同的团队负责流水线的不同部分。

好了，今天先写到这，各位看官可以先消化一下，想一想，你所在的项目 CICD 流水线是怎么做的呢，还有没有提升的空间呢？
调整一下 CICD 流水线图，现在应该是下面这样子的。Jenkins 作为 CICD 服务器起到非常关键的作用，这也是大部分项目实施 CICD 的现状。注意，这里的 CD 是 Continuous Delivery。

但是，你有没有考虑过这些问题呢？

• 必须在 Jenkins 上面安装和设置一些工具，例如 kubectl，helm 等

• 在 Jenkins 上配置 credentials，这些工具才可以访问 Kubernetes 集群

• 如果是EKS，那还得配置 Jenkins credentials 以访问 AWS 云平台

• 因为需要把 Kubernetes cluster credential 提供给外部服务和客户端工具，这就引发了安全问题。尤其是部署多个项目的应用到集群，为了只允许访问特定的 Kubernetes 集群，每个项目有自己的 Kubernetes credentials。更有甚者，如果是很多个集群呢？那这个配置工作就变得繁琐了，安全隐患也更大。

• 最重要的是，Jenkins 执行完 CD 流水线后，部署状态是不可见的。也就是，kubectl apply 之后，Jenkins 是不知道它的执行状态的，资源是否被创建，服务是否更新成功且为健康状态，你只能通过接下来的测试步骤去确认。

所以，CD 这一部分是有提升空间的。这时候，就该 Argo CD 入场了，以上这些痛点，它都有自己的解决方案，让持续交付到 Kubernetes 集群更有效率。Argo CD 就是基于 GitOps 的原则为 Kubernetes 而诞生的。

Argo CD 是如何工作的？

那么 Argo CD 是如何提高 CD 效率的呢？我们换位思考一下，把 kubectl apply 到集群这个步骤反转过来，不再从外面去访问 Kubernetes 集群。以前是在集群外面通过 push 的方式去更新资源，现在是集群中有一个 Argo CD agent，它作为集群的一部分使用拉取（pull）的方式，从 git repo 上面拉取 yaml 文件，然后更新资源。

现在来看看用 Argo CD 替代 Jenkins 后，CD 流水线应该是怎样的。概括起来，有下面这几个步骤。

1. 部署 Argo CD 到 Kubernetes 集群

2. 配置 Argo CD 以监控 Git repository 的更新

3. 如果 Argo CD 监控到有更新，自动拉取这些更新，然后更新到 Kubernetes 集群

这里有个关于 Git repository 的最佳实践。

为什么要把业务代码和 Kubernetes yaml file 单独放在不同的 git 仓库呢？其中一个主要的原因是，配置代码不仅仅有 k8s deployment yaml 文件，还有 ConfigMap，Secret，Service，Ingress 等等其它 Kubernetes 资源，当我们只需要更新这些 yaml 文件时，可以独立于业务代码，不会触发 CI pipeline，因为业务代码本身并没有任何更新。也不需要，在 CI pipeline 中写一些复杂的逻辑去检查有哪些更新。这个配置代码库也被称之为 GitOps Repository。

现在整个 CICD 流水线是下面这样子的。

Argo CD 支持 Kubernetes YAML 文件，Helm Charts，Kustomize(kustomize.io) ，还有其它最终会生成为 YAML 格式的模版文件。

我们最终拥有了单独的CI 流水线和 CD 流水线。一般情况下，CI 流水线由开发者或者 DevOps 负责，CD 流水线由 Ops 或者 DevOps 负责（使用 Argo CD）。这样的好处是，不仅有自动化的 CICD 流水线，还能达到关注点分离的目的，不同的团队负责流水线的不同部分。

好了，今天先写到这，各位看官可以先消化一下，想一想，你所在的项目 CICD 流水线是怎么做的呢，还有没有提升的空间呢？