在過去十年的編程中，出現(xiàn)了一些革命性的轉(zhuǎn)變。其中之一是源于圍繞DevOps的實(shí)踐，它將開發(fā)和運(yùn)維團(tuán)隊(duì)整合到一個(gè)共享的工作流程中，此外還有持續(xù)集成和持續(xù)交付（CI/CD），通過CI/CD，Devops團(tuán)隊(duì)可以向代碼庫提供持續(xù)的更新。另一個(gè)變革來自于從單體代碼庫到基于云的微服務(wù)的遷移，這些微服務(wù)運(yùn)行在由Kubernetes等編排平臺(tái)管理的容器中。

即使有Kubernetes這樣的平臺(tái)來編排協(xié)調(diào)，在集群系統(tǒng)或云端運(yùn)行的基于容器的應(yīng)用程序依舊可能是復(fù)雜的、難以調(diào)配和管理的。GitOps是一套新興的實(shí)踐，旨在通過應(yīng)用Devops和CI/CD世界的技術(shù)來簡化這一管理任務(wù)。

GitOps的關(guān)鍵是基礎(chǔ)設(shè)施即代碼（IaC）的理念，它采用與DevOps用于提供應(yīng)用程序一樣的方法來提供基礎(chǔ)設(shè)施。所以，不僅是應(yīng)用，還有底層的主機(jī)和網(wǎng)絡(luò)都被描述在文件中，這些文件可以像版本控制系統(tǒng)中的其他代碼一樣，然后由自動(dòng)化流程來將現(xiàn)實(shí)世界的應(yīng)用與這些文件中描述的應(yīng)用進(jìn)行融合。

用GitOps的說法，版本控制系統(tǒng)中的代碼是關(guān)于應(yīng)用在生產(chǎn)中應(yīng)該是什么樣子的唯一真相來源（single source of truth）。

定義GitOps

Weaveworks是在GitOps概念普及方面貢獻(xiàn)最大的公司。稍后我們會(huì)詳細(xì)介紹Weaveworks在其中扮演的角色，但首先，我們先來看看該公司對GitOps的定義，它有兩個(gè)方面：

• Kubernetes和其他云原生技術(shù)的運(yùn)維模式，為統(tǒng)一部署、管理和監(jiān)控容器化集群和應(yīng)用提供了一套最佳實(shí)踐。

• GitOps是一條通往管理應(yīng)用的開發(fā)者體驗(yàn)之路；在這里，端到端的CI/CD流水線和Git workflow可以同時(shí)應(yīng)用于運(yùn)維和開發(fā)。

換句話說，GitOps是一套特定的實(shí)踐，旨在管理Kubernetes和類似的平臺(tái)。隨著越來越多的開發(fā)團(tuán)隊(duì)采用DevOps實(shí)踐，并將代碼遷移到云端，GitOps也將會(huì)適合更廣泛的應(yīng)用。但要了解GitOps的秘訣和它所能解決的問題，我們需要談?wù)勊慕M成部分。

Git定義

在GitOps中Git指的是由Linus Torvalds在2005年開發(fā)的極為流行的分布式版本控制系統(tǒng)。Git是一個(gè)工具，它允許開發(fā)者團(tuán)隊(duì)在一個(gè)應(yīng)用程序代碼庫上共同工作，存儲(chǔ)各種代碼分支，在將它們合并到生產(chǎn)代碼之前，他們可以對這些代碼進(jìn)行修補(bǔ)。Git 的一個(gè)關(guān)鍵概念是拉取請求，即開發(fā)人員正式要求將他們正在編寫的一些代碼整合到代碼庫的另一個(gè)分支中。

Git 拉取請求為團(tuán)隊(duì)成員提供了一個(gè)協(xié)作和討論的機(jī)會(huì)，然后再就是否應(yīng)該將新代碼添加到應(yīng)用程序中達(dá)成共識(shí)。Git 還會(huì)存儲(chǔ)舊版本的代碼，如果出了問題，可以很容易地回滾到上一個(gè)好的版本，并可以讓你快速查看兩次修改之間的變化。Git 最為人所知的部分可能是作為GitHub 這一云端托管版本控制系統(tǒng)的底層，但 Git 本身也是一個(gè)開源軟件，可以部署在任何地方，無論是公司內(nèi)部的服務(wù)器還是你的PC。

需要注意的是，雖然我們通常認(rèn)為Git是一個(gè)計(jì)算機(jī)編程工具，但實(shí)際上取決于你如何使用它。Git 很樂意將任何文本文件作為你的 “代碼庫”，例如，它可以被作者用來記錄合作作品的編輯情況。這一點(diǎn)很重要，因?yàn)镚itOps的核心代碼庫大多由聲明式配置文件而非可執(zhí)行代碼組成。

在我們繼續(xù)之前，最后要強(qiáng)調(diào)一件事——盡管名字中就有 “Git”，但GitOps實(shí)際上并不必要使用Git。已經(jīng)投入使用其他版本控制軟件（如Subversion）的團(tuán)隊(duì)也可以實(shí)現(xiàn)GitOps。但在Devops領(lǐng)域，Git被廣泛用于實(shí)現(xiàn)CI/CD，所以大多數(shù)GitOps項(xiàng)目最終都會(huì)使用Git。

什么是CI/CD流程？

關(guān)于CI/CD的完整解釋其實(shí)不在本文討論的范圍內(nèi)，但是因?yàn)镃I/CD是 GitOps 工作的核心，因此我們需要對其進(jìn)行簡單的介紹。CI/CD中的一半持續(xù)集成是由版本控制倉庫（如Git）實(shí)現(xiàn)的。開發(fā)者可以對代碼庫進(jìn)行持續(xù)的小改進(jìn)，而不是每隔幾個(gè)月或幾年就推出巨大的、單一的新版本。持續(xù)部署這一塊是通過被稱為流水線（pipeline）的自動(dòng)化系統(tǒng)來實(shí)現(xiàn)的，這些流水線可以構(gòu)建、測試和部署新的代碼到生產(chǎn)中。

同樣，我們在這里一直在談?wù)摯a，這通常會(huì)讓人聯(lián)想到用C語言、Java或JavaScript等編程語言編寫的可執(zhí)行代碼。但在GitOps中，我們所管理的 “代碼” 主要是由配置文件組成的。這不是一個(gè)小細(xì)節(jié)，而是GitOps工作的核心。正如我們所說，這些配置文件是描述我們的系統(tǒng)應(yīng)該是什么樣子的 “唯一真理來源（single source of truth）”。它們是聲明式的，而不是指導(dǎo)性的。這意味著，配置文件不會(huì)說 “啟動(dòng)十臺(tái)服務(wù)器”，而會(huì)簡單地說 “這個(gè)系統(tǒng)包括十臺(tái)服務(wù)器”。

GitOps方程中的CI那一半允許開發(fā)人員快速推出對這些配置文件的調(diào)整和改進(jìn)；當(dāng)自動(dòng)化軟件代理竭盡全力確保應(yīng)用程序的實(shí)時(shí)版本能夠反映配置文件中的描述時(shí)，CD這一部分會(huì)以GitOps語言趨向于聲明式模型。

GitOps和Kubernetes

正如我們所提到的，GitOps的概念最初是圍繞管理Kubernetes應(yīng)用而出現(xiàn)的。通過我們現(xiàn)在對GitOps的了解，讓我們重溫一下Weaveworks的GitOps討論，看看他們是如何描述如何對基于GitOps原則管理的Kubernetes進(jìn)行更新的。下面是對整個(gè)流程的總結(jié)：

• 一個(gè)開發(fā)者為一個(gè)新功能提出Git 拉取請求。

• 審查和批準(zhǔn)代碼，然后將其合并到主代碼庫中。

• 合并會(huì)觸發(fā) CI/CD 流水線、自動(dòng)測試和重建新代碼，并將其部署到倉庫。

• 軟件代理注意到更新，從倉庫中提取新代碼，并更新配置倉庫中的配置文件（用YAML編寫）。

• Kubernetes集群中的軟件代理根據(jù)配置文件，檢測到集群已經(jīng)過時(shí)，拉取更改，并部署新功能。

Weaveworks和GitOps

顯然，這里的第4步和第5步做了很多繁重的工作。將Git倉庫中的 "真理來源 "與現(xiàn)實(shí)世界中的Kubernetes應(yīng)用進(jìn)行神奇同步的軟件代理，就是讓GitOps成為可能的魔法。正如我們所說，在GitOps術(shù)語中，讓實(shí)時(shí)系統(tǒng)更像配置文件中描述的理想系統(tǒng)的過程叫做融合。當(dāng)實(shí)時(shí)系統(tǒng)和理想系統(tǒng)不同步時(shí)，那就是分歧。理想情況下，融合可以通過自動(dòng)化流程來實(shí)現(xiàn)，但自動(dòng)化所能做的事情是有限度的，有時(shí)人工干預(yù)是必要的。

我們在這里用通用術(shù)語描述了這個(gè)過程，但事實(shí)上，如果你真的去看Weaveworks的頁面，我們提到的 “軟件代理” 是該公司W(wǎng)eave Cloud平臺(tái)的一部分?！癎itOps” 這個(gè)詞是由Weaveworks的CEO Alexis Richardson創(chuàng)造的，它的部分作用是讓W(xué)eaveworks平臺(tái)對已經(jīng)沉浸在DevOps和CI/CD世界的開發(fā)者有吸引力。

但Weaveworks從未宣稱自己壟斷了GitOps，GitOps更多的是一種理念和一套最佳實(shí)踐，而不是某種具體的產(chǎn)品。正如提供CI/CD解決方案的公司CloudBees的博客所指出的那樣，GitOps代表了一種開放的、廠商中立的模式，它是針對亞馬遜、谷歌和微軟等大型云廠商推出的管理型專有Kubernetes解決方案而開發(fā)的。CloudBees提供了自己的GitOps解決方案，這個(gè)領(lǐng)域的另一些玩家也是如此。

GitOps和DevOps

Atlassian是一家為敏捷開發(fā)者制造了許多工具的公司，它有一篇關(guān)于GitOps的歷史和目的的深度博文（https://www.atlassian.com/git/tutorials/gitops），值得你花時(shí)間去了解。在他們看來，GitOps代表了作為devops的理念的邏輯延伸。具體來說，GitOps是對基礎(chǔ)架構(gòu)即代碼（IaC）這一概念的闡述，而基礎(chǔ)架構(gòu)本身就是DevOps環(huán)境下產(chǎn)生的一種思想。在Atlassian看來，GitOps彌補(bǔ)了現(xiàn)有DevOps技術(shù)與分布式、云托管應(yīng)用的特殊需求之間的關(guān)鍵差距，現(xiàn)有DevOps技術(shù)是為了解決系統(tǒng)管理問題而發(fā)展起來的。各個(gè)云廠商提供的自動(dòng)融合是GitOps的特別之處。

雖然GitOps今天仍然專注于Kubernetes，但我們希望我們已經(jīng)明確了它如何適用于更廣泛的分布式、基于云的應(yīng)用世界。開源安全廠商WhiteSource的一篇博文概述了GitOps的優(yōu)勢：

• 可觀察性：GitOps系統(tǒng)為復(fù)雜的應(yīng)用提供了監(jiān)控、日志、跟蹤和可視化功能，因此開發(fā)人員可以看到什么地方出現(xiàn)了故障，在哪里出現(xiàn)了故障。

• 版本控制和變更管理：很明顯，這是使用Git這樣的版本控制系統(tǒng)的一個(gè)關(guān)鍵優(yōu)勢。有缺陷的更新可以輕松回滾。

• 易于采用：GitOps建立在許多開發(fā)人員已經(jīng)掌握的開發(fā)技能之上。

• 提高生產(chǎn)力：GitOps 可以像開發(fā)項(xiàng)目和 CI/CD 那樣提高工作效率。

• 審計(jì)：有了Git，每一個(gè)操作都可以追蹤到一個(gè)特定的提交，這樣就可以很容易地追蹤到錯(cuò)誤的原因。

即使你不使用Kubernetes，GitOps也很有可能遲早會(huì)成為你工作流程的一部分。