?在編程領域，最近十年，發生了許多革命性的變化。其中之一，便是圍繞devop的一系列實踐，這些實踐將開發和運營團隊整合到一個共享的工作流程中，并實現了持續集成和持續交付（CI/CD），其中devops團隊會不斷向代碼庫提供了增量的更新。另一個轉變來自相關的轉變，從單個代碼庫，轉變到運行在業務平臺（如Kubernetes）管理的容器中的基于云的微服務。

在集群系統或云中運行的基于容器的應用程序可能很復雜，并且即使使用像Kubernetes這樣的平臺來協調事物，也很難對其進行配置和管理。GitOps是一組新興實踐，旨在通過應用devops和CI / CD領域的技術來簡化此管理任務。

GitOps的關鍵在于基礎設施即代碼的理念，它采用與devops提供應用程序相同的方法來提供基礎設施。因此，不僅應用程序，而且底層的主機和網絡都在文件中進行描述，這些文件可以作為版本控制系統中的任何其他代碼來處理，然后將真實的應用程序與這些文件中描述的應用程序融合在一起。

用GitOps的說法，版本控制系統中的代碼是關于應用程序在生產環境中應該是什么樣子的唯一來源。

GitOps定義 

Weaveworks是為推廣GitOps概念所做的最大努力的公司。我們將詳細介紹Weaveworks的角色，但首先，讓我們看一下該公司對GitOps的定義，它有兩個方面：

• Kubernetes和其他云原生技術的運行模型，提供了一組最佳實踐，這些最佳實踐統一了容器化集群和應用程序的部署，管理和監視。
• 通往開發人員管理應用程序體驗的途徑；端到端CI / CD管道和Git工作流同時應用于運營和開發。

換句話說，GitOps是一組專門為管理Kubernetes和類似平臺而設計的實踐，隨著越來越多的開發機構采用devops實踐并將代碼遷移到云上，它也可以應用于更廣泛的應用。但是為了理解GitOps的秘密武器和它所解決的問題，我們需要談談它的組成部分。

Git定義 

GitOps中的Git是指Linus Torvalds在2005年開發的非常流行的分布式版本控制系統。Git是一種工具，它允許開發團隊在一個應用程序代碼庫上共同工作，存儲他們在將代碼合并到生產代碼之前對其進行修改的各種代碼分支。Git中的一個關鍵概念是pull request，在這個概念中，開發人員正式要求將他們一直在工作的一些代碼集成到代碼庫中的另一個分支中。

Git pull請求為團隊成員提供了一個協作和討論的機會，然后就是否應該將新代碼添加到應用程序達成一致意見。Git還存儲了較舊版本的代碼，這使得在出現錯誤時很容易回到上一個好版本，并讓您快速查看不同版本之間的更改。Git最出名的可能是作為GitHub的基礎，GitHub是一種云托管版本控制系統，但是Git本身是一種開源軟件，可以部署在任何地方，從公司內部的服務器到你的個人電腦。

請注意，雖然我們通常認為Git是一種計算機編程工具，但它實際上并不知道您使用它來做什么內容。Git將樂于將任何文本文件集作為“代碼庫”，例如，作者可以使用它來跟蹤協作工作的編輯。這一點很重要，因為GitOps核心的大部分代碼基由聲明性配置文件組成，而不是可執行代碼。

在我們繼續之前，還有最后一件事要說:盡管名稱中有“Git”，但GitOps實際上并不需要使用Git。已經投入了其他版本控制軟件(如Subversion)的公司也可以實現GitOps。但是Git在devops中被廣泛用于實現CI/CD，所以大多數GitOps項目最終都將使用Git。

CI / CD流程是什么？

對CI/CD的完整了解超出了本文的范圍，但我們需要對CI/CD說幾句，因為它是GitOps運作的核心。CI/CD的持續集成部分是由像Git這樣的版本控制庫支持的:開發人員可以對他們的代碼庫進行持續的小改進，而不是每隔幾個月或幾年就推出一個巨大的、單一的新版本。連續部署部分是由稱為管道的自動化系統實現的，這些系統構建、測試并將新代碼部署到生產環境中。

同樣，我們在這里一直在討論代碼，這通常會讓人聯想到用C、Java或JavaScript等編程語言編寫的可執行代碼。但在GitOps中，我們管理的“代碼”主要是由配置文件組成的。這不僅僅是一個小細節——這是GitOps工作的核心。正如我們所說的，這些配置文件是描述我們的系統應該是什么樣子的“真實的單一來源”。它們是陳述性的，而不是啟發性的。這意味著配置文件不是說“啟動10臺服務器”，而是簡單地說“這個系統包括10臺服務器”。

GitOps等式的CI部分允許開發者快速地對這些配置文件進行調整和改進;當自動化軟件代理盡其所能確保應用程序的活版本反映配置文件中的描述時，CD的一半就發生了——它用GitOps的語言聚合到聲明式模型。

GitOps和Kubernetes

如前所述，GitOps的概念最初是圍繞管理Kubernetes應用程序開發的。有了我們現在對GitOps的了解，讓我們再來看看Weaveworks對GitOps的討論。這里有一個總結:

1、開發人員為一個新特性發出一個Git pull請求。

2、代碼會被審查和批準，然后合并到主代碼庫中。

3、合并將觸發CI/CD管道，該管道將自動測試并重新構建新代碼，并將其部署到注冊表中。

4、軟件代理注意到更新，從注冊表中提取新代碼，并更新配置存儲庫中的配置文件(用YAML編寫)。

5、Kubernetes集群中的一個軟件代理根據配置文件檢測集群過期，提取更改并部署新特性。

Weaveworks和GitOps

顯然，步驟4和步驟5是最重要的部分。神奇地將Git存儲庫中的“真相之源”與真實的Kubernetes應用程序同步的軟件代理使GitOps成為可能。正如我們所說的，在GitOps術語中，使動態系統更像配置文件中描述的理想系統的過程稱為收斂。(當動態系統和理想系統不同步時，就是發散。)理想情況下，融合可以通過自動化過程來實現，但是自動化所能做的是有限的，有時需要人工干預。

我們在這里用通用的術語描述了這個過程，但實際上，如果你真的去看Weaveworks的頁面，我們提到的“軟件代理”是該公司Weave云平臺的一部分。“GitOps”一詞是由Weaveworks首席執行官Alexis Richardson創造的，這在一定程度上是為了讓Weaveworks平臺吸引那些已經沉浸在devops和CI/CD世界的開發者。

但Weaveworks從未宣稱壟斷過GitOps，它更像是一種哲學和一套最佳實踐，而不是一種特定的產品。正如CloudBees(一家提供CI/CD解決方案的公司)的博客所指出的，GitOps代表了一種開放的、與供應商無關的模型，這種模型是針對大型云供應商如亞馬遜、谷歌和微軟推出的托管專有Kubernetes解決方案而開發的。CloudBees提供了自己的GitOps解決方案，該領域的許多參與者也是如此。

GitOps和devops

Atlassian是一家為敏捷開發人員提供多種工具的公司，它有一篇關于GitOps歷史和目的的深度博客，值得你花時間去了解。在他們看來，GitOps代表了devops中各種想法的邏輯延伸。具體地說，GitOps是對“基礎設施即代碼”概念的精化，它本身就是源自devops環境的一個想法。在Atlassian看來，GitOps填補了現有devops技術與分布式云托管應用程序之間的關鍵差距，后者已經發展到解決系統管理問題的程度。各種云供應商提供的自動融合正是GitOps的獨特之處。

盡管GitOps今天仍然專注于Kubernetes，我們希望我們已經明確了它是如何應用于更廣泛的分布式、基于云的應用的。開源安全廠商WhiteSource的一篇博客文章概述了GitOps的優勢:

• 可觀察性：GitOps系統提供對復雜應用程序的監視、日志記錄、跟蹤和可視化，這樣開發人員就可以看到哪里出了問題。
• 版本控制和變更管理：顯然，這是使用像Git這樣的版本控制系統的一個關鍵好處。有缺陷的更新可以輕松回滾。
• 易于采用：GitOps建立在許多開發人員已經具備的devops技能之上。
• 生產力：GitOps提高了生產力，就像devops和CI/CD帶給其他領域的生產力一樣。
• 審計：由于有了Git，每個操作都可以跟蹤到一個特定的提交，這使得跟蹤錯誤的原因變得更加容易。

即使你不使用Kubernetes, GitOps遲早也會成為你工作流程的一部分。

*原文鏈接：https://www.infoworld.com/article/3566555/what-is-gitops-extending-devops-to-kubernetes-and-beyond.html?