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 流水線是怎么做的呢，還有沒有提升的空間呢？