如何使用Argo CD和GitOps解決配置漂移問題

這篇文章將為大家詳細講解有關如何使用Argo CD和GitOps解決配置漂移問題，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

Argo CD（Argo項目的一部分）是一個為Kubernetes而設的部署解決方案，遵循GitOps模式。

使用Argo CD部署到Kubernetes

在最基本的場景中，Argo CD使用Kubernetes清單持續監視Git倉庫（也支持Helm和Kustomize）并監聽提交事件。

當發生提交（通常是更新鏡像工件版本的提交）時，Argo CD會啟動一個“同步（synchronization）”進程，該進程負責使集群配置處于與Git中描述的相同的狀態。

當同步過程完成時，我們知道應用程序配置與Git清單完全相同。

Argo CD的部署過程體現了GitOps背后的核心理念：

• 所有應用程序配置都存儲在Git中（通常在與源代碼不同的存儲庫中）

• 部署以一種“拉”方式進行，即集群從Git獲取清單（而不是將更新“推”到集群的傳統解決方案）。

• 部署是兩種狀態之間的協調過程（Git中描述的狀態與集群中部署的狀態）

盡管同步過程對于執行應用程序的初始部署是至關重要的，但Argo CD真正的優勢之一是在部署完成后能夠持續監控兩個狀態（集群和Git）。這種持續的監視對于解決配置漂移非常重要，配置漂移在具有大量部署目標的組織中是一個非常常見的問題。

不同Kubernetes集群之間的配置漂移

配置漂移是一個即使在傳統虛擬機中也存在的問題，而且早在Kubernetes出現之前，它就一直困擾著生產部署。當CI/CD平臺執行到多個目標的部署并失敗時，問題就會顯現出來，因為一組本應相似的機器實際上配置不同。

在一些組織中，開發人員在應用程序部署到生產環境之前使用“登臺（staging）”環境來測試其應用程序。理想情況下，登臺環境應該與生產環境的配置相匹配，這樣開發人員就可以確信他們在登臺中執行的任何測試都將與生產環境緊密匹配。

特別是在Kubernetes集群中，團隊經常使用特別的命令（例如，通過kubectl）在一個完全不在CI/CD進程之外的集群上執行更改。

這些特別的更改是應用程序部署的一個主要問題。配置上的差異是導致部署失敗的最常見原因之一。在登臺環境中成功通過所有測試的應用程序在生產中會出現中斷狀態，因為沒有提供所需的設置或采用預期的格式。

另一個由配置漂移引起的隱藏問題是，逐漸丟失了在機器/節點上部署了什么以及最后一次更改的確切時間的知識。Argo CD解決了這個問題，它將Git作為當前部署和過去所有部署的真實來源。

在部署失敗后，運營者和開發人員試圖了解事故的原因，他們問的第一個問題是“這個集群最后發生的變化是什么”。如果集群在批準的CI/CD進程之外發生了未控制的更改，那么這個問題很難回答。

Argo CD如何檢測配置漂移問題

Argo CD采用了一種完全不同的部署方法（“pull from Git”范式）。因為所有部署都可以追溯到Git提交，所以Git提交歷史記錄也是集群部署歷史記錄。

開發人員可以使用他們喜歡的Git工具來回答諸如“上周四集群上部署了什么？”或者“這周周一到周四之間發生了什么變化？”

讓我們假設團隊中的一個人完全繞過了Argo CD，并使用kubectl直接對集群進行手動更改。其他CI/CD解決方案將完全忽略此更改，這為配置漂移問題提供了環境。

Argo CD會理解集群上發生了變化，這兩種狀態（集群配置和Git清單）不再相同。部署將立即標記為“不同步（out-of-sync）”。

Argo CD也將挖掘得更深入，甚至提供了一個很好的差異概述，改變了什么：

在上面的例子中，Argo CD檢測到集群和Git之間服務的端口配置不再相同。

當你檢測到這樣的差異，你可以手動使應用程序處于與Git相同的狀態（再次執行同步過程），或者指示Argo CD在檢測到配置更改時自動進行自身的同步。

這意味著Argo CD配置的漂移（至少對Kubernetes應用程序而言）完全消除了，特別是在啟用了自動同步行為的情況下。

使用Argo CD的團隊可以放心地進行部署，因為他們知道集群處于它應該處于的狀態（該狀態在Git清單中也有完整的描述）。配置漂移不再是一個問題，保持登臺和生產過程盡可能接近是一個非常簡單的過程。

Argo與Devops平臺的結合

除了Argo CD的主要項目，你可能也會發現Argo Rollouts項目很有趣。Argo Rollouts是Argo的另一個項目，用于對Kubernetes進行漸進式（藍/綠/灰度）部署。

https://argoproj.github.io/argo-rollouts/

Argo CD和Argo Rollouts對于處理應用程序部署來說是非常好的，但是它們需要與一個完整的自動化解決方案相結合，這個解決方案也將處理軟件生命周期的所有其他方面，比如應用程序構建、單元測試、秘密管理和拉取請求處理等。

Argo CD非常適合實際部署，但它假設工件已經由另一個解決方案創建。這就是為什么我們一直努力將Codefresh和Argo集成在一起，以覆蓋整個軟件生命周期，甚至覆蓋自動將變更推送到Argo監控manifest的Git倉庫的場景（即執行自動提交，從而實踐持續部署）。

關于如何使用Argo CD和GitOps解決配置漂移問題就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。