本文轉自Rancher Labs
在過去十年的程式設計中，出現了一些革命性的轉變。其中之一是源於圍繞DevOps的實踐，它將開發和運維團隊整合到一個共享的工作流程中，此外還有持續整合和持續交付（CI/CD），通過CI/CD，Devops團隊可以向程式碼庫提供持續的更新。另一個變革來自於從單體程式碼庫到基於雲的微服務的遷移，這些微服務執行在由Kubernetes等編排平臺管理的容器中。
即使有Kubernetes這樣的平臺來編排協調，在叢集系統或雲端執行的基於容器的應用程式依舊可能是複雜的、難以調配和管理的。GitOps是一套新興的實踐，旨在通過應用Devops和CI/CD世界的技術來簡化這一管理任務。
GitOps的關鍵是基礎設施即程式碼（IaC）的理念，它採用與DevOps用於提供應用程式一樣的方法來提供基礎設施。所以，不僅是應用，還有底層的主機和網路都被描述在檔案中，這些檔案可以像版本控制系統中的其他程式碼一樣，然後由自動化流程來將現實世界的應用與這些檔案中描述的應用進行融合。
用GitOps的說法，版本控制系統中的程式碼是關於應用在生產中應該是什麼樣子的唯一真相來源（single source of truth）。
定義GitOps
Weaveworks是在GitOps概念普及方面貢獻最大的公司。稍後我們會詳細介紹Weaveworks在其中扮演的角色，但首先，我們先來看看該公司對GitOps的定義，它有兩個方面：
-
Kubernetes和其他雲原生技術的運維模式，為統一部署、管理和監控容器化叢集和應用提供了一套最佳實踐。
-
GitOps是一條通往管理應用的開發者體驗之路；在這裡，端到端的CI/CD流水線和Git workflow可以同時應用於運維和開發。
換句話說，GitOps是一套特定的實踐，旨在管理Kubernetes和類似的平臺。隨著越來越多的開發團隊採用DevOps實踐，並將程式碼遷移到雲端，GitOps也將會適合更廣泛的應用。但要了解GitOps的祕訣和它所能解決的問題，我們需要談談它的組成部分。
Git定義
在GitOps中Git指的是由Linus Torvalds在2005年開發的極為流行的分散式版本控制系統。Git是一個工具，它允許開發者團隊在一個應用程式程式碼庫上共同工作，儲存各種程式碼分支，在將它們合併到生產程式碼之前，他們可以對這些程式碼進行修補。Git 的一個關鍵概念是拉取請求，即開發人員正式要求將他們正在編寫的一些程式碼整合到程式碼庫的另一個分支中。
Git 拉取請求為團隊成員提供了一個協作和討論的機會，然後再就是否應該將新程式碼新增到應用程式中達成共識。Git 還會儲存舊版本的程式碼，如果出了問題，可以很容易地回滾到上一個好的版本，並可以讓你快速檢視兩次修改之間的變化。Git 最為人所知的部分可能是作為GitHub 這一雲端託管版本控制系統的底層，但 Git 本身也是一個開源軟體，可以部署在任何地方，無論是公司內部的伺服器還是你的PC。
需要注意的是，雖然我們通常認為Git是一個計算機程式設計工具，但實際上取決於你如何使用它。Git 很樂意將任何文字檔案作為你的 “程式碼庫”，例如，它可以被作者用來記錄合作作品的編輯情況。這一點很重要，因為GitOps的核心程式碼庫大多由宣告式配置檔案而非可執行程式碼組成。
在我們繼續之前，最後要強調一件事——儘管名字中就有 “Git”，但GitOps實際上並不必要使用Git。 已經投入使用其他版本控制軟體（如Subversion）的團隊也可以實現GitOps。但在Devops領域，Git被廣泛用於實現CI/CD，所以大多數GitOps專案最終都會使用Git。
什麼是CI/CD流程？
關於CI/CD的完整解釋其實不在本文討論的範圍內，但是因為CI/CD是 GitOps 工作的核心，因此我們需要對其進行簡單的介紹。CI/CD中的一半持續整合是由版本控制倉庫（如Git）實現的。開發者可以對程式碼庫進行持續的小改進，而不是每隔幾個月或幾年就推出巨大的、單一的新版本。持續部署這一塊是通過被稱為流水線（pipeline）的自動化系統來實現的，這些流水線可以構建、測試和部署新的程式碼到生產中。
同樣，我們在這裡一直在談論程式碼，這通常會讓人聯想到用C語言、Java或JavaScript等程式語言編寫的可執行程式碼。但在GitOps中，我們所管理的 “程式碼” 主要是由配置檔案組成的。這不是一個小細節，而是GitOps工作的核心。正如我們所說，這些配置檔案是描述我們的系統應該是什麼樣子的 “唯一真理來源（single source of truth）”。它們是宣告式的，而不是指導性的。這意味著，配置檔案不會說 “啟動十臺伺服器”，而會簡單地說 “這個系統包括十臺伺服器”。
GitOps方程中的CI那一半允許開發人員快速推出對這些配置檔案的調整和改進；當自動化軟體代理竭盡全力確保應用程式的實時版本能夠反映配置檔案中的描述時，CD這一部分會以GitOps語言趨向於宣告式模型。
GitOps和Kubernetes
正如我們所提到的，GitOps的概念最初是圍繞管理Kubernetes應用而出現的。通過我們現在對GitOps的瞭解，讓我們重溫一下Weaveworks的GitOps討論，看看他們是如何描述如何對基於GitOps原則管理的Kubernetes進行更新的。下面是對整個流程的總結：
-
一個開發者為一個新功能提出Git 拉取請求。
-
審查和批准程式碼，然後將其合併到主程式碼庫中。
-
合併會觸發 CI/CD 流水線、自動測試和重建新程式碼，並將其部署到倉庫。
-
軟體代理注意到更新，從倉庫中提取新程式碼，並更新配置倉庫中的配置檔案（用YAML編寫）。
-
Kubernetes叢集中的軟體代理根據配置檔案，檢測到叢集已經過時，拉取更改，並部署新功能。
Weaveworks和GitOps
顯然，這裡的第4步和第5步做了很多繁重的工作。將Git倉庫中的 "真理來源 "與現實世界中的Kubernetes應用進行神奇同步的軟體代理，就是讓GitOps成為可能的魔法。正如我們所說，在GitOps術語中，讓實時系統更像配置檔案中描述的理想系統的過程叫做融合。當實時系統和理想系統不同步時，那就是分歧。理想情況下，融合可以通過自動化流程來實現，但自動化所能做的事情是有限度的，有時人工干預是必要的。
我們在這裡用通用術語描述了這個過程，但事實上，如果你真的去看Weaveworks的頁面，我們提到的 “軟體代理” 是該公司Weave Cloud平臺的一部分。“GitOps” 這個詞是由Weaveworks的CEO Alexis Richardson創造的，它的部分作用是讓Weaveworks平臺對已經沉浸在DevOps和CI/CD世界的開發者有吸引力。
但Weaveworks從未宣稱自己壟斷了GitOps，GitOps更多的是一種理念和一套最佳實踐，而不是某種具體的產品。 正如提供CI/CD解決方案的公司CloudBees的部落格所指出的那樣，GitOps代表了一種開放的、廠商中立的模式，它是針對亞馬遜、谷歌和微軟等大型雲廠商推出的管理型專有Kubernetes解決方案而開發的。CloudBees提供了自己的GitOps解決方案，這個領域的另一些玩家也是如此。
GitOps和DevOps
Atlassian是一家為敏捷開發者製造了許多工具的公司，它有一篇關於GitOps的歷史和目的的深度博文（https://www.atlassian.com/git/tutorials/gitops ），值得你花時間去了解。在他們看來，GitOps代表了作為devops的理念的邏輯延伸。具體來說，GitOps是對基礎架構即程式碼（IaC）這一概念的闡述，而基礎架構本身就是DevOps環境下產生的一種思想。在Atlassian看來，GitOps彌補了現有DevOps技術與分散式、雲託管應用的特殊需求之間的關鍵差距，現有DevOps技術是為了解決系統管理問題而發展起來的。各個雲廠商提供的自動融合是GitOps的特別之處。
雖然GitOps今天仍然專注於Kubernetes，但我們希望我們已經明確了它如何適用於更廣泛的分散式、基於雲的應用世界。開源安全廠商WhiteSource的一篇博文概述了GitOps的優勢：
-
可觀察性：GitOps系統為複雜的應用提供了監控、日誌、跟蹤和視覺化功能，因此開發人員可以看到什麼地方出現了故障，在哪裡出現了故障。
-
版本控制和變更管理：很明顯，這是使用Git這樣的版本控制系統的一個關鍵優勢。有缺陷的更新可以輕鬆回滾。
-
易於採用：GitOps建立在許多開發人員已經掌握的開發技能之上。
-
提高生產力：GitOps 可以像開發專案和 CI/CD 那樣提高工作效率。
-
審計：有了Git，每一個操作都可以追蹤到一個特定的提交，這樣就可以很容易地追蹤到錯誤的原因。
即使你不使用Kubernetes，GitOps也很有可能遲早會成為你工作流程的一部分。