GitOps 這個(gè)概念最早是由 Kubernetes 管理公司 Weaveworks 公司在 2017 年提出的，如今已經(jīng)過去了 5 個(gè)年頭，想必大家對這個(gè)概念早有耳聞，但你可能并不知道它到底是什么，它和 DevOps 到底是啥關(guān)系，本文就來幫大家一一解惑。

基礎(chǔ)設(shè)施即代碼

在理解 GitOps 之前，我們需要先理解什么是基礎(chǔ)設(shè)施即代碼。

基礎(chǔ)設(shè)施即代碼（Infrastructure as Code, IaC），顧名思義，表示使用代碼（而非手動(dòng)流程）來定義基礎(chǔ)設(shè)施，研發(fā)人員可以像對待應(yīng)用軟件一樣對待基礎(chǔ)設(shè)施，例如：

• 可以創(chuàng)建包含基礎(chǔ)架構(gòu)規(guī)范的聲明式配置文件，從而便于編輯和分發(fā)配置。
• 可以確保每次配置的環(huán)境都完全相同。
• 可以進(jìn)行版本控制，所有的變更都會(huì)被記錄下來，方便溯源。
• 可以將基礎(chǔ)設(shè)施劃分為若干個(gè)模塊化組件，并通過自動(dòng)化以不同的方式進(jìn)行組合。

當(dāng)然，廣義上的 IaC 不僅僅只關(guān)于基礎(chǔ)設(shè)施，還包含了網(wǎng)絡(luò)、安全、配置等等，所以廣義上的 IaC 又叫 X as Code。

比如你想在 AWS 中創(chuàng)建服務(wù)器，配置網(wǎng)絡(luò)，部署 Kubernetes 集群以及各種工作負(fù)載，你只需要定義好 Terraform 或 Ansible 的聲明式配置，以及 Kubernetes 的配置清單即可，免去一切繁雜的手動(dòng)操作。

GitOps 是什么

GitOps = IaC + Git + CI/CD，即基于 IaC 的版本化 CI/CD。它的核心是使用 Git 倉庫來管理基礎(chǔ)設(shè)施和應(yīng)用的配置，并且以 Git 倉庫作為基礎(chǔ)設(shè)施和應(yīng)用的單一事實(shí)來源，你從其他地方修改配置（比如手動(dòng)改線上配置）一概不予通過。

Git 倉庫中的聲明式配置描述了目標(biāo)環(huán)境當(dāng)前所需基礎(chǔ)設(shè)施的期望狀態(tài)，借助于 GitOps，如果集群的實(shí)際狀態(tài)與 Git 倉庫中定義的期望狀態(tài)不匹配，Kubernetes reconcilers 會(huì)根據(jù)期望狀態(tài)來調(diào)整當(dāng)前的狀態(tài)，最終使實(shí)際狀態(tài)符合期望狀態(tài)。

另一方面，現(xiàn)代應(yīng)用的開發(fā)更多關(guān)注的是迭代速度和規(guī)模，擁有成熟 DevOps 文化的組織每天可以將代碼部署到生成環(huán)境中數(shù)百次，DevOps 團(tuán)隊(duì)可以通過版本控制、代碼審查以及自動(dòng)測試和部署的 CI/CD 流水線等最佳實(shí)踐來實(shí)現(xiàn)這一目標(biāo)，這就是 GitOps 干的事情。

GitOps vs DevOps

從廣義上來看，GitOps 與 DevOps 并不沖突，GitOps 是一種技術(shù)手段，而 DevOps 是一種文化。GitOps 是一種實(shí)現(xiàn)持續(xù)交付（Continuous Delivery）、持續(xù)部署（Continuous Deployment）和基礎(chǔ)設(shè)施即代碼（IaC）的工具和框架，它是支持 DevOps 文化的。

從狹義上來看，GitOps 與 DevOps 有以下幾個(gè)區(qū)別：

首先，GitOps 是以目標(biāo)為導(dǎo)向的。它使用 Git 來維護(hù)期望狀態(tài)，并不斷調(diào)整實(shí)際狀態(tài)，最終與期望狀態(tài)相匹配。而 DevOps 更多關(guān)注的是最佳實(shí)踐，這些實(shí)踐可以普遍應(yīng)用于企業(yè)的每一個(gè)流程。

其次，GitOps 采取聲明式的操作方法，而 DevOps 同時(shí)接受聲明式和命令式的方法，所以 DevOps 除了適用于容器環(huán)境之外，還適用于虛擬機(jī)和裸機(jī)環(huán)境。

最后，GitOps 重新定義了云原生場景下的 CI/CD，它以 Git 作為中心的不可變狀態(tài)聲明，以加快持續(xù)部署速度。

GitOps 的設(shè)計(jì)哲學(xué)

想要使用 GitOps 來管理你的基礎(chǔ)設(shè)施和應(yīng)用，需要踐行以下幾個(gè)原則：

1. 聲明式

必須通過聲明式來描述系統(tǒng)的期望狀態(tài)。例如 Kubernetes，眾多現(xiàn)代云原生工具都是聲明式的，Kubernetes 只是其中的一種。

2. 版本控制/不可變

因?yàn)樗械臓顟B(tài)聲明都存儲(chǔ)在 Git 倉庫中，并且把 Git 倉庫作為單一事實(shí)來源，那么所有的操作都是從 Git 倉庫里驅(qū)動(dòng)的，而且保留了完整的版本歷史，方便回滾。有了 Git 優(yōu)秀的安全保障，也可以使用 SSH 密鑰來簽署 commits，對代碼的作者和出處實(shí)施強(qiáng)有力的安全保障。

3. 自動(dòng)應(yīng)用變更

Git 倉庫中聲明的期望狀態(tài)發(fā)生了任何變更，都可以立即應(yīng)用到系統(tǒng)中，而且不需要安裝配置額外工具（比如 kubectl），也不需要配置 Kubernetes 的認(rèn)證授權(quán)。

4. 持續(xù)的 Reconciliation

Reconciliation 其實(shí)最早是 Kubernetes 里的一個(gè)概念，表示的是確保系統(tǒng)的實(shí)際狀態(tài)與期望狀態(tài)一致的過程。具體的實(shí)現(xiàn)方式是在目標(biāo)環(huán)境中安裝一個(gè) agent，一旦實(shí)際狀態(tài)與期望狀態(tài)不匹配，agent 就會(huì)進(jìn)行自動(dòng)修復(fù)。這里的修復(fù)比 Kubernetes 的故障自愈更高級，即使是手動(dòng)修改了集群的編排清單，集群也會(huì)被恢復(fù)到 Git 倉庫中的清單所描述的狀態(tài)。

鑒于以上這些設(shè)計(jì)哲學(xué)，我們來看一下 GitOps 的工作流：

• 首先，團(tuán)隊(duì)中的任何一個(gè)成員都可以 Fork 倉庫對配置進(jìn)行更改，然后提交 Pull Request。
• 接下來會(huì)運(yùn)行 CI 流水線，一般會(huì)做這么幾件事情：驗(yàn)證配置文件、執(zhí)行自動(dòng)化測試、檢測代碼的復(fù)雜性、構(gòu)建 OCI 鏡像、將鏡像推送到鏡像倉庫等等。
• CI 流水線運(yùn)行完成后，團(tuán)隊(duì)中擁有合并代碼權(quán)限的人將會(huì)將這個(gè) Pull Request 合并到主分支中 。一般擁有這個(gè)權(quán)限的都是研發(fā)人員、安全專家或者高級運(yùn)維工程師。
• 最后會(huì)運(yùn)行 CD 流水線，將變更應(yīng)用到目標(biāo)系統(tǒng)中（比如 Kubernetes 集群或者 AWS） 。

整個(gè)過程完全自動(dòng)化且透明，通過多人協(xié)作和自動(dòng)化測試來保證了基礎(chǔ)設(shè)施聲明配置的健壯性。而傳統(tǒng)的模式是其中一個(gè)工程師在自己的電腦上操作這一切，其他人不知道發(fā)生了什么，也無法對其操作進(jìn)行 Review。

Push vs Pull

CD 流水線有兩種模式：Push 和 Pull。

Push 模式

目前大多數(shù) CI/CD 工具都使用基于 Push 的部署模式，例如 Jenkins、CircleCI 等。這種模式一般都會(huì)在 CI 流水線運(yùn)行完成后執(zhí)行一個(gè)命令（比如 kubectl）將應(yīng)用部署到目標(biāo)環(huán)境中。

這種 CD 模式的缺陷很明顯：

• 需要安裝配置額外工具（比如 kubectl）；
• 需要 Kubernetes 對其進(jìn)行授權(quán)；
• 需要云平臺(tái)授權(quán)；
• 無法感知部署狀態(tài)。也就無法感知期望狀態(tài)與實(shí)際狀態(tài)的偏差，需要借助額外的方案來保障一致性。

Kubernetes 集群或者云平臺(tái)對 CI 系統(tǒng)的授權(quán)憑證在集群或云平臺(tái)的信任域之外，不受集群或云平臺(tái)的安全策略保護(hù)，因此 CI 系統(tǒng)很容易被當(dāng)成非法攻擊的載體。

Pull 模式

Pull 模式會(huì)在目標(biāo)環(huán)境中安裝一個(gè) Agent，例如在 Kubernetes 集群中就靠 Operator 來充當(dāng)這個(gè) Agent。Operator 會(huì)周期性地監(jiān)控目標(biāo)環(huán)境的實(shí)際狀態(tài)，并與 Git 倉庫中的期望狀態(tài)進(jìn)行比較，如果實(shí)際狀態(tài)不符合期望狀態(tài)，Operator 就會(huì)更新基礎(chǔ)設(shè)施的實(shí)際狀態(tài)以匹配期望狀態(tài)。

只有 Git 的變更可以作為期望狀態(tài)的唯一來源，除此之外，任何人都不可以對集群進(jìn)行任何更改，即使你修改了，也會(huì)被 Operator 還原為期望狀態(tài)，這也就是傳說中的不可變基礎(chǔ)設(shè)施。

目前基于 Pull 模式的 CD 工具有 Argo CD[1]，F(xiàn)lux CD[2] 以及 ks-devops[3]。

GitOps 的優(yōu)勢

一般 GitOps 首選的都是基于 Pull 的部署模式，因?yàn)檫@種模式有很多不可替代的優(yōu)勢。

更強(qiáng)大的安全保障

上面已經(jīng)提到了，使用 GitOps 不需要任何 Kubernetes 或者云平臺(tái)的憑證來執(zhí)行部署，Kubernetes 集群內(nèi)的 Argo CD 或者 Flux CD 只需要訪問 Git 倉庫，并通過 Pull 模式來更新即可。

另一方面，Git 由用于跟蹤和管理代碼變更的強(qiáng)大密碼學(xué)支持，擁有對變更進(jìn)行簽名以證明作者身份和來源的能力，這是保障集群安全的關(guān)鍵。

Git 作為事實(shí)的唯一真實(shí)來源

因?yàn)樗械膽?yīng)用包括基礎(chǔ)設(shè)施的聲明式配置都保存在 Git 中，并把 Git 作為應(yīng)用系統(tǒng)的唯一事實(shí)來源，因此可以利用 Git 的強(qiáng)大功能操作所有東西，例如版本控制、歷史記錄、審計(jì)和回滾等等，無需使用 kubectl 這樣的工具來操作。

提高生產(chǎn)力

Git 也是開發(fā)人員非常熟悉的工具，通過 Git 不斷迭代，可以提高生產(chǎn)率，加快開發(fā)和部署速度，更快地推出新產(chǎn)品，同時(shí)提高系統(tǒng)的穩(wěn)定性和可靠性。

更容易合規(guī)的審計(jì)

使用 GitOps 的基礎(chǔ)設(shè)施可以像任何軟件項(xiàng)目一樣使用 Git 來管理，所以同樣可以對其進(jìn)行質(zhì)量審計(jì)。當(dāng)有人需要對基礎(chǔ)設(shè)施進(jìn)行更改時(shí)，會(huì)創(chuàng)建一個(gè) Pull Request，等相關(guān)人員對其進(jìn)行 Code Review 之后，更改才可以應(yīng)用到系統(tǒng)中。

總結(jié)

GitOps 是對現(xiàn)有 DevOps 文化的補(bǔ)充，它使用 Git 這樣的版本控制系統(tǒng)來自動(dòng)部署基礎(chǔ)設(shè)施，部署過程清晰可見，可以查看和跟蹤對系統(tǒng)進(jìn)行的任何變更，提高了生產(chǎn)力、安全性和合規(guī)性。而且 GitOps 提供了更優(yōu)雅的可觀測性，可以實(shí)時(shí)觀測部署狀態(tài)，并采取行動(dòng)使實(shí)際狀態(tài)與期望狀態(tài)保持一致。

而且在 GitOps 中，整個(gè)系統(tǒng)都是通過聲明式來描述的，天然適合云原生環(huán)境，因?yàn)?Kubernetes 也是這么設(shè)計(jì)的。

參考資料

• What is GitOps and what should you know about it?[4]
• DevOps vs GitOps: 4 Benefits you must know to Master the Methodologies[5]
• Guide To GitOps[6]

引用鏈接

[1]Argo CD: https://github.com/argoproj/argo-cd/

[2]Flux CD: https://github.com/fluxcd/flux

[3]ks-devops: https://github.com/kubesphere/ks-devops

[4]What is GitOps and what should you know about it?: https://devs-group.medium.com/what-is-gitops-and-what-should-you-know-about-it-fcaa3e3c1dd5

[5]DevOps vs GitOps: 4 Benefits you must know to Master the Methodologies: https://www.tynybay.com/our-thinking/devops-vs-gitops-4-benefits-you-must-know-to-master-the-methodologies

[6]Guide To GitOps: https://www.weave.works/technologies/gitops/