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

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

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

使用Argo CD部署到Kubernetes

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

當(dāng)發(fā)生提交（通常是更新鏡像工件版本的提交）時，Argo CD會啟動一個“同步（synchronization）”進(jìn)程，該進(jìn)程負(fù)責(zé)使集群配置處于與Git中描述的相同的狀態(tài)。

當(dāng)同步過程完成時，我們知道應(yīng)用程序配置與Git清單完全相同。

Argo CD的部署過程體現(xiàn)了GitOps背后的核心理念：

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

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

• 部署是兩種狀態(tài)之間的協(xié)調(diào)過程（Git中描述的狀態(tài)與集群中部署的狀態(tài)）

盡管同步過程對于執(zhí)行應(yīng)用程序的初始部署是至關(guān)重要的，但Argo CD真正的優(yōu)勢之一是在部署完成后能夠持續(xù)監(jiān)控兩個狀態(tài)（集群和Git）。這種持續(xù)的監(jiān)視對于解決配置漂移非常重要，配置漂移在具有大量部署目標(biāo)的組織中是一個非常常見的問題。

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

配置漂移是一個即使在傳統(tǒng)虛擬機(jī)中也存在的問題，而且早在Kubernetes出現(xiàn)之前，它就一直困擾著生產(chǎn)部署。當(dāng)CI/CD平臺執(zhí)行到多個目標(biāo)的部署并失敗時，問題就會顯現(xiàn)出來，因?yàn)橐唤M本應(yīng)相似的機(jī)器實(shí)際上配置不同。

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

特別是在Kubernetes集群中，團(tuán)隊(duì)經(jīng)常使用特別的命令（例如，通過kubectl）在一個完全不在CI/CD進(jìn)程之外的集群上執(zhí)行更改。

這些特別的更改是應(yīng)用程序部署的一個主要問題。配置上的差異是導(dǎo)致部署失敗的最常見原因之一。在登臺環(huán)境中成功通過所有測試的應(yīng)用程序在生產(chǎn)中會出現(xiàn)中斷狀態(tài)，因?yàn)闆]有提供所需的設(shè)置或采用預(yù)期的格式。

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

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

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

Argo CD采用了一種完全不同的部署方法（“pull from Git”范式）。因?yàn)樗胁渴鸲伎梢宰匪莸紾it提交，所以Git提交歷史記錄也是集群部署歷史記錄。

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

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

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

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

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

當(dāng)你檢測到這樣的差異，你可以手動使應(yīng)用程序處于與Git相同的狀態(tài)（再次執(zhí)行同步過程），或者指示Argo CD在檢測到配置更改時自動進(jìn)行自身的同步。

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

使用Argo CD的團(tuán)隊(duì)可以放心地進(jìn)行部署，因?yàn)樗麄冎兰禾幱谒鼞?yīng)該處于的狀態(tài)（該狀態(tài)在Git清單中也有完整的描述）。配置漂移不再是一個問題，保持登臺和生產(chǎn)過程盡可能接近是一個非常簡單的過程。

Argo與Devops平臺的結(jié)合

除了Argo CD的主要項(xiàng)目，你可能也會發(fā)現(xiàn)Argo Rollouts項(xiàng)目很有趣。Argo Rollouts是Argo的另一個項(xiàng)目，用于對Kubernetes進(jìn)行漸進(jìn)式（藍(lán)/綠/灰度）部署。

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

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

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

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