本文轉自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也很有可能遲早會成為你工作流程的一部分。