Git，作為開發(fā)過程中的核心工具，提供了強大的版本控制功能。即便在寫代碼的時候稍微手抖一下，我們也能通過 Git 的差異對比（diff）輕松追蹤到龐大工程中的問題，確保代碼的準(zhǔn)確與可靠。這種無與倫比的自省能力，不僅提高了工作效率，也帶來了極大的安全感，讓一切都有跡可循。

如果上面的這些能力在運維上也能實現(xiàn)，是不是穩(wěn)定性會特別好，變更時候想出故障都難？任何非預(yù)期的變化都能通過diff對比出來？是的。GitOps就是基于這些觸發(fā)點而產(chǎn)生的。2017年Weaveworks的CEO Alexis Richardson 提出了這個概念：通過一個模型抽象使得整個系統(tǒng)的操作變得自動化，使用Git來承載這個模型。

不過這么多年過去了，GitOps相關(guān)的產(chǎn)品和平臺層出不窮，除了WeaveWorks，似乎大家對GitOps各有各的理解和實踐：似乎解決了一些問題，但似乎又沒完全解決。那么，問題到底出在哪里？GitOps到底能為我們帶來些什么？本文嘗試展開講講這個問題。

首先，我們先從日常的工作開始思考，我們到底希望GitOps幫我們實現(xiàn)哪些目標(biāo)？我先列了三個目標(biāo)，大家看看是不是也有類似的想法：

• 變更自動化：只要把代碼提交到git中，就進(jìn)行自動構(gòu)建、自動測試、自動部署，不要讓我到處點按鈕。
• 變更代碼化：變更到底會變哪些東西，影響哪些基礎(chǔ)設(shè)施，能否直接在代碼中就能看出？不要在一句“風(fēng)險可控”背后藏著一個沒人能理得清的操作流程。
• 變更透明化：變更信息中包含所有的源碼變化，不要包含一些無法展開的引用關(guān)系：比如容器鏡像tag變化需要有對應(yīng)的構(gòu)建源碼的變化。

帶著這三個目標(biāo)，我們先去找找業(yè)界對于GitOps的定義，看看是否能找到一些線索：

一、GitOps是什么

云原生基金會（CNCF）在2021年成立了一個OpenGitOps工作組，旨在推廣GitOps的最佳實踐。在這個工作組的官網(wǎng)首頁放著四條GitOps的原則：

• Declarative：聲明式
• Versioned and Immutable：版本化且不可變
• Pulled Automatically：自動拉取
• Continuously Reconciled：持續(xù)調(diào)和

這四條原則基本是WeaveWorks的GitOps定義的一個深化，而且較多地推薦使用Flux進(jìn)行GitOps實踐，有關(guān)這塊介紹，我們會在第三章展開。鑒于這個工作組中能得到的有效信息實在太少，我們繼續(xù)尋找業(yè)界有關(guān)GitOps的介紹。

GitLab出版過一本電子書叫《A beginners guide to GitOps》（下載地址在參考材料中），在書中提出了一個概念公式：GitOps = IaC + MRs + CI/CD。這個概念就比前面的GitOps四原則更具體一些了：

• IaC (Infrastructure as Code)： 指出GitOps管理模型就應(yīng)該是IaC，這比原則中的Declarative更進(jìn)了一步：這不僅僅是關(guān)于聲明性配置，而是關(guān)于將整個基礎(chǔ)設(shè)施的管理嵌入到代碼之中，從而實現(xiàn)更精確和可重復(fù)的部署過程。
• MRs (Merge Requests)：明確指出，在 GitOps 中，管理動作不是通過直接提交代碼來完成，而是通過一系列的合并請求（Merge Request）。這種方法允許進(jìn)行更深入的風(fēng)險評估和審計，在代碼合并到生產(chǎn)環(huán)境之前確保質(zhì)量和安全。
• CI/CD (Continuous Integration/Continuous Delivery)：GitOps 的最終目標(biāo)是實現(xiàn)代碼的自動化集成和持續(xù)交付：既確保嚴(yán)格的測試驗證，又能加速開發(fā)周期，保持高質(zhì)量和穩(wěn)定性。

在第四章，我們會展開說說如何基于這個公式去進(jìn)行GitOps實踐。

本來我的覺得GitOps差不多概念也就這樣了，基本上幾大廠商的觀點都看過了。沒想到又在亞馬遜上看到了一本書《Repeatability, Reliability, and Scalability through GitOps》（購買鏈接在參考材料中），閱讀之后對于GitOps的認(rèn)知又拓寬了不少，作者在書中提出了三種類型的GitOps：

• The Original GitOps: 原始GitOps，即k8s做IaC，然后落地GitOps的方案。
• The Purist GitOps: 純粹GitOps，不一定基于k8s，但是基于某種IaC+GitOps進(jìn)行落地的方案，使用終態(tài)的方式來進(jìn)行管理。
• The Verified GitOps: 驗證型GitOps，也不一定有終態(tài)管理，只要確保整個過程中有g(shù)it diff能驗證即可。

說實話，第三種類型的GitOps讓我豁然開朗，這種GitOps確實更貼近實際落地：IaC的改造推廣常常會有較大的成本，而在沒有改造完之前，就不能享受GitOps帶來的好處了嗎？作者告訴我們一種選擇，這種以驗證為目的GitOps就行。

作者為了讓我們更能深入地理解這個驗證型GitOps，還畫了一張流程示意圖：紅色部分為人工，綠色部分為自動。從圖中可以看到，自動的流程在右側(cè)自動流轉(zhuǎn)，左側(cè)分別是development、devops、sre三種角色在根據(jù)git diff進(jìn)行驗證審計。

二、Infrastructure as Code要怎么做

通過前面一些概念，我們能看到聲明式&IaC在gitops中占據(jù)非常重要的部分?？梢赃@樣說，如果IaC無法承載所有的運維編排能力，運維編排需求可以會外溢到其他系統(tǒng)或平臺上，那么這部分外溢的邏輯就無法使用Git來追蹤了：所以這個IaC的聲明式的編排能力會變得尤為重要。

在分析IaC方案之前，我們先來看看聲明式編程（Declarative）和命令式編程（Imperative）的區(qū)別：

• 常見的聲明式編程語言有SQL和HTML，我們來寫個常見的例子：

# 使用SQL查詢數(shù)據(jù)庫中的年齡超過30歲的用戶
SELECT name, age FROM users WHERE age > 30;

• 常見的命令式編程包括過程式編程（Procedural Programming）和面向?qū)ο缶幊?#xff08;Object-Oriented Programming），還是上面的這個查詢年齡超過30歲的用戶的例子，使用Python寫則會變成這樣

users = [{"name": "Alice", "age": 25}, {"name": "Bob", "age": 35}, {"name": "Carol", "age": 32}]
users_over_30 = []
for user in users:if user["age"] > 30:users_over_30.append(user)

通過這兩個例子大家可以明顯地感覺到聲明式編程的可讀性更強，描述結(jié)果并且只關(guān)注結(jié)果；與之相對應(yīng)的是，過程式編程需要理解整個過程，才能知道這段代碼在干什么。

我們來列一下市面上比較流行的IaC方案：

• Terraform：HashiCorp公司于2014年創(chuàng)建，提供人們使用HashiCorp Configuration Language（HCL）來聲明式編寫基礎(chǔ)設(shè)施的能力。Terraform的社區(qū)生態(tài)非常活躍，其provider支持幾乎所有的云廠商。
• Crossplane：Crossplane 是在 2018 年由 Upbound 公司推出，旨在通過擴展 Kubernetes 的能力，提供統(tǒng)一的多云和混合云環(huán)境下的基礎(chǔ)設(shè)施即服務(wù)（IaaS）管理解決方案。
• Pulumi： Pulumi是在2017年由幾位前微軟員工成立的Pulumi Corp 創(chuàng)立的。與Terraform等工具不同，Pulumi允許使用常用的編程語言（如Python、TypeScript、JavaScript等）來定義和部署基礎(chǔ)設(shè)施，從而使得基礎(chǔ)設(shè)施代碼更容易理解和維護。

光這樣講會有些抽象，我們圍繞著一個例子來比較一下這幾種IaC方案，如何來創(chuàng)建一個阿里云ECS：

從上面的例子可以看到，Terraform作為早期的IaC方案，這樣聲明確實大大簡化基礎(chǔ)設(shè)施的使用成本，只要幾行代碼就能申請出一臺虛擬機。Crossplane是擴展k8s的能力，所以每種基礎(chǔ)設(shè)施都是一個CRD。但標(biāo)準(zhǔn)的YAML也帶來一個問題就是遇到一些復(fù)雜的條件渲染，就無能為力了，它不像Terraform的HCL能夠在語言中增加一些模板類的控制語句，它需要通過自定義控制器來解決，這無疑增加了IaC交付的難度。

Pulumi明顯吸收了Terraform的經(jīng)驗：既然IaC中的模板等控制流無法避免，與其想方設(shè)法設(shè)計包含過程函數(shù)的聲明式編程語言，不如我干脆就還是用普通編程語言，只是在SDK中引導(dǎo)用戶聲明式編程，保留用戶使用控制語句的權(quán)利。

雖然各種IaC提供了非常方便的基礎(chǔ)設(shè)施交付方案，但事實上如果真正進(jìn)行工程化的使用，就會遇到一個狀態(tài)存儲的問題。每個IaC都必須將狀態(tài)存儲下來，才是一份完整的冪等聲明，如下圖所示：

如果沒有這份狀態(tài)文件，反復(fù)執(zhí)行同一份IaC聲明，就會不斷地創(chuàng)建資源。對于GitOps而言，所有的變化都必須可以被git commit追蹤：這份狀態(tài)文件同樣至關(guān)重要，已經(jīng)創(chuàng)建過的資源不能再創(chuàng)建，否則可能就會產(chǎn)生生產(chǎn)故障。

由于狀態(tài)文件維護的復(fù)雜性，但有些用戶又垂涎IaC聲明式交付的便利，就會衍生出這樣的半吊子的使用場景：只用IaC進(jìn)行資源創(chuàng)建，后續(xù)維護依然使用原有的模式，這樣就不用管理創(chuàng)建時產(chǎn)生的狀態(tài)文件。 事物存在即合理，也不能說這樣的方案有什么問題，但確實從另外一個側(cè)面反映出一個問題：IaC的聲明代碼無法表達(dá)全部終態(tài)，必須要加上狀態(tài)文件才構(gòu)成冪等完整的終態(tài)。這個問題也帶給我們了一個提醒：GitOps需要將狀態(tài)也納入進(jìn)去，否則無法達(dá)成前面提到的“變更透明化”這個目標(biāo)。

三、GitOps相關(guān)產(chǎn)品分析

分析完了IaC方案，我們繼續(xù)來看GitOps相關(guān)產(chǎn)品，我們來分析一下：由于GitOps是在k8s社區(qū)中發(fā)展起來，所以現(xiàn)在市面上的GitOps基本都是圍繞著k8s容器編排展開，如我們第一章所提到 The Original GitOps（原始GitOps）。

我們首先來看看最老牌的CI/CD工具Jenkins在k8s下的演進(jìn)：Jenkins X。

通過這張架構(gòu)圖我們可以看出Jenkins X在k8s場景下，放棄了原有的JenkinsFile的構(gòu)建編排能力，轉(zhuǎn)而使用Tekton來進(jìn)行構(gòu)建流水線的編排。Jenkins整體的側(cè)重CI的，在Jenkins X中依然如此，流水線主要是為CI服務(wù)，在流水線的末端會有幾個CD節(jié)點將實例部署到目標(biāo)環(huán)境。這種CI/CD串聯(lián)的方案適合小型工程，對于大一些的工程，其CD能力則會有些捉襟見肘，因為畢竟只是幾個shell命令的組合。

從整體上看，Jenkins X能夠?qū)崿F(xiàn)“變更自動化”，但其他方面則稍顯不足。

然后我們來看一下ArgoCD，這是在GitOps領(lǐng)域的當(dāng)紅炸子雞，它通過一個Application的CRD實現(xiàn)了k8s的YAML的控制權(quán)的轉(zhuǎn)移。需要操作k8s集群的需求，轉(zhuǎn)變成了在git中提交git commit。下面是ArgoCD的GitOps架構(gòu)圖：

ArgoCD和Jenkins X這類方案比起來少了很多功能，但架不住它簡單好用：只需要把Helm包推到git上，他就會被自動部署到k8s環(huán)境之上。ArgoCD的這種純CD的方案有個自動化的短板就是：在CI環(huán)節(jié)構(gòu)建完的容器鏡像，需要手工把他們拷貝到Helm包中，然后提交git。雖然說這種鏡像地址的人肉拷貝也是個常見的行為，但是畢竟我們當(dāng)前是在調(diào)研完整的GitOps方案，如果從源頭上就不支持，那只能說他在“變更自動化”這塊存在不足。

最后，我們來看一下FluxCD，這是GitOps概念提出者WeaveWorks公司的開源產(chǎn)品。這個FluxCD確實屬于對GitOps的踐行產(chǎn)物，在ArgoCD中僅用Application蓋住的概念，在這里被分成了Source、Helm、Image Automation 等，分別有對應(yīng)的控制器來負(fù)責(zé)干活：

不得不說，FluxCD中的概念還是非常完整的，同時它也有ImageUpdateAutomation這樣一個對象，專門用來進(jìn)行鏡像的自動更新、如果在鏡像倉庫中出現(xiàn)新鏡像，它就會自動提交一個git commit把對應(yīng)的鏡像字段更新，這個機制完美地解決了ArgoCD中人手工拷貝的問題：不過度介入CI環(huán)節(jié)，但對于CI環(huán)節(jié)的制品能自動感知，自動部署。

四、GitOps動手實踐

通過前三章節(jié)的介紹，我們對GitOps的構(gòu)成基本清晰了，復(fù)用一下GitLab中的那個公式基本就是 GitOps = IaC + MRs + CI/CD，不過從IaC開始做存在較大挑戰(zhàn)，畢竟需要從源頭改變整個鏈路，我們可以先從CI/CD開始。

我們先嘗試解決第一個問題“變更透明化”：增強對于構(gòu)建環(huán)節(jié)的制品采集能力，將每個制品的sha256、git commit以及名稱全部采集到數(shù)據(jù)庫。盡量不改變原有的CI流程，在CI最終出制品的節(jié)點后將信息采回。

有了制品信息之后，我們就能對每次復(fù)雜的變更進(jìn)行源碼下探，遇到鏡像變更，就制品倉庫中找到對應(yīng)的源碼進(jìn)一步下探（inspect），使得原本兩眼一抹黑的鏡像變化，也變得清晰透明。

事實上，從The Verified GitOps（驗證型GitOps）的角度看，基于制品做變更透視方案已經(jīng)將GitOps達(dá)成了。不過我們一開始定的目標(biāo)還有兩個沒有完全達(dá)成：變更自動化、變更代碼化。自動化這塊其實反倒是簡單，在CI的最后一個節(jié)點接上變更平臺的接口即可。變更代碼化這塊則需要我們設(shè)計一套聲明式的方案來編排整個變更鏈路：這里最大的挑戰(zhàn)是對于已有流程和平臺的整合。

IaC的語法設(shè)計是個苦差事，這么多大牛前仆后繼，市面的IaC語言似乎總無法完全用聲明的方式，解決基礎(chǔ)設(shè)施編排的問題。Pulumi這套方案給了我們很大的啟發(fā)，既然這樣，為何不直接用現(xiàn)有的編程語言？

于是我們借鑒Pulumi設(shè)計了一套SRE Stack方案：

• 我們提供sre_stack供用戶在熟悉的編程環(huán)境（以Python為例）下編排他的變更過程。
• IaC代碼 + 狀態(tài)文件構(gòu)成了完整的變更描述，彌補了terraform這類的IaC工具在狀態(tài)管理中的不足。
• 狀態(tài)文件本質(zhì)上也是一張數(shù)據(jù)快照，對于包含外部系統(tǒng)的數(shù)據(jù)的一個快照，所以可以友好地實現(xiàn)跨平臺的數(shù)據(jù)整合。

有人可能就會問，如果有人不在sre_stack.py中維護終態(tài)，轉(zhuǎn)而在外部系統(tǒng)中維護數(shù)據(jù)是不是也是可以的。是的，本身這個方案就考慮到了對原有系統(tǒng)的整合，所以這種情況是允許的，但我們能結(jié)構(gòu)化地檢查和審計出來：如果sre_stack.py文件沒有變化，而status文件變化了，意味著這是一個非IaC驅(qū)動的終態(tài)變化。如果我們能接受這次變化（畢竟某些低頻的復(fù)雜操作可能確實沒那么適合在IaC中表達(dá)），只要審批過了，下次就不會再出現(xiàn)。整個流程如下圖所示：

針對開分支，開發(fā)者提交了MergeRequest之后，會自動觸發(fā)SRE Stack的狀態(tài)渲染，將status文件補全進(jìn)代碼中，因此在審批環(huán)節(jié)就能完整地看到變化，在本章的開頭部分，我們已經(jīng)對于制品管理以及透視機制有了介紹，因此在通過IaC下的產(chǎn)生的變更透視樹就變成了下面的樣子：

于是，通過SRE Stack+制品管理，我們基本實現(xiàn)了這三個目標(biāo)：

• 變更自動化：只要修改stack文件，發(fā)起MergeRequest，就進(jìn)行自動渲染、自動部署，如果將代碼構(gòu)建的最后一個節(jié)點變成修改stack文件，就能實現(xiàn)CI到CD的無縫銜接。
• 變更代碼化：stack文件中，使用聲明的方式描述了變更的目標(biāo)和行為，使得我們只要查看stack文件和狀態(tài)文件，就能知道這次變更的內(nèi)容是什么。
• 變更透明化：通過CI環(huán)節(jié)的制品信息采集，在最終的變更審批環(huán)節(jié)，我們能夠透視出包含源碼的完整的變更棧，不再有無法展開的引用關(guān)系。

五、總結(jié)

當(dāng)前GitOps體系已經(jīng)在內(nèi)部逐步使用推廣，有相應(yīng)需求的公司可以聯(lián)系SREWorks進(jìn)行開源共建，我們可以將其作為一款SREWorks運維應(yīng)用逐步對外推出。

參考材料

1. weaveworks blog: The History of GitOps The History of GitOps
2. OpenGitOps工作組官網(wǎng) Home | OpenGitOps
3. 《A beginners guide to GitOps》GitLab
4. 《Repeatability, Reliability, and Scalability through GitOps》Amazon.com
5. 《Pulumi 到底比 Terraform 強在哪》Pulumi 到底比 Terraform 強在哪
6. 《Crossplane 是下一代 IaC 么》Crossplane 是下一代 IaC 么
7. 《規(guī)模化環(huán)境Terraform狀態(tài)管理技巧》規(guī)?；h(huán)境Terraform狀態(tài)管理技巧
8. 《FluxCD, ArgoCD or Jenkins X: Which Is the Right GitOps Tool for You?》FluxCD, ArgoCD or Jenkins X: Which Is the Right GitOps Tool for You?
9. 《Tekton入門介紹》Tekton入門介紹-騰訊云開發(fā)者社區(qū)-騰訊云
10. 《Automatic image update in Git with FluxCD》Automatic image update in Git with FluxCD