今天給大家分享的是 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 流水線是怎麼做的呢，還有沒有提升的空間呢？