譯者 | 崔瑩峰
審校 | 孫淑娟 梁策
在這篇文章中，我們將探索 GitOps 如何為基于容器化和微服務開發(fā)云原生解決方案的組織提供最佳服務。
什么是 GitOps，為什么它對組織很重要?
GitOps 是一種自動化和管理基礎設施和應用程序的模型，它通過許多團隊已經使用過的相同 DevOps 最佳實踐來完成，例如版本控制、代碼審查和 CI/CD 管道等等。在實施 DevOps 過程中，我們雖然在軟件開發(fā)生命周期找到了自動化的方法，但在基礎設施安裝和部署方面，仍然需要手工處理。使用 GitOps，團隊可以自動化基礎設施配置過程。這得益于我們能夠將基礎架構作為代碼 (IaC)編寫、在 Git 倉庫中對代碼進行版本控制以及基于云交付進行持續(xù)部署。
因為它具有提高生產力和軟件質量的巨大潛力，很多公司一直在采用 GitOps，而它也最適合開發(fā)基于容器化和微服務的云原生解決方案的組織。
GitOps 如何改善開發(fā)人員和運維人員的日常工作?
GitOps 帶來的基礎設施自動化的增長創(chuàng)造了為應用程序開發(fā)人員開發(fā)更具有“自助服務”方法的機會。熟練的開發(fā)人員可以使用基礎設施即代碼來聲明他們的云資源需求，而不是協(xié)商云資源。這成為對基礎設施的期望狀態(tài)，集中存儲起來并可以用作代碼中聲明的需求與運行環(huán)境的實際狀態(tài)之間的不可變參考點。
自助服務方法解放了開發(fā)人員。它讓開發(fā)人員更有效率，使他們能夠專注于創(chuàng)新，并讓他們的應用程序更快地推向市場。此外，它避免了開發(fā)人員和運營人員需要協(xié)商資源時可能引入的泥潭。
另一方面，經常存在一種誤解，即運營自動化程度的提高意味著運營團隊需要更少的人員，并且運營在管道中的角色正被邊緣化。我們的觀點恰恰相反;我們認為 GitOps 和??內部開發(fā)平臺??等現代方法為 Ops(平臺團隊)提供了振奮人心的機會，以提高他們的技能并為組織創(chuàng)造更多價值。在一個采用 GitOps 的高水平的云原生軟件開發(fā)組織中，您可能會發(fā)現正是因為存在一個不斷壯大的平臺團隊才讓一切工作正常。
平臺團隊使用的實際技術可能會有所不同。在某些情況下，這可能只是一個封閉的 PaaS 解決方案。在其他情況下，它可以是創(chuàng)建適合組織需求的定制平臺各種工具的組合。這使他們能夠對基礎設施資源和架構施加更大的影響和控制，并創(chuàng)建“護欄”，以執(zhí)行簡單、高效和標準化的云原生應用程序部署方法。
GitOps 有助于改善開發(fā)人員和運營團隊之間的協(xié)作，提高他們的生產力，并增加部署頻率。它使開發(fā)人員無需了解底層基礎架構即可貢獻功能，從而增強了開發(fā)人員的體驗。同時，它通過代碼審查和批準來控制操作。通過這些改進，團隊可以更快、更安全地發(fā)布，以保持其在市場中的地位。
實施 GitOps 的三個必做步驟是什么?
如果想讓公司實施的 GitOps 模型發(fā)揮最大優(yōu)勢，例如整體工作流程的標準化和一致性，您需要考慮以下幾點。
一切皆為代碼
- 聲明你的 IaC。
- 使用 Git 倉庫進行 IaC 開發(fā)。
- 將屬于應用程序代碼生命周期一部分的實踐也復制到基礎架構代碼中。
- 使用 Docker 和 Kubernetes 等技術，將您的環(huán)境、版本、配置和依賴項定義為代碼，并確保它們在運行時得到強制執(zhí)行。
- 逐漸將 GitOps 模型擴展到可以定義為代碼的任何事物，例如安全性、策略、合規(guī)性以及基礎架構之外的所有操作。
圖1： 一切皆為代碼
聲明式代碼提高了可讀性和可維護性。CloudFormation、Terraform、Pulumi 和 Crossplane 是一些可能的聲明性語言，您可以使用這些語言來定義您的基礎架構配置。
當一切都定義為代碼時，您可以使用 Git 倉庫進行開發(fā)并探索諸如版本控制、協(xié)作和審計等內容。
審核流程
一個正確的 Git 流程包括：
- 主分支，通常代表一個環(huán)境，如 dev、test、stage、prod 和在該環(huán)境上運行的狀態(tài)。
- 當開發(fā)人員需要對代碼進行更改時，他們會從主分支創(chuàng)建一個新分支。
- 當更改準備就緒時，開發(fā)人員會創(chuàng)建一個拉取請求，該請求應該由運營團隊審核以驗證和批準。安全和合規(guī)專家也可以參與此階段，正確地驗證環(huán)境的狀態(tài)。
- 一旦獲得批準，代碼就可以合并到主分支并交付到測試或生產環(huán)境。
使用此工作流程，您可以跟蹤誰進行了哪些更改并確保環(huán)境具有正確的代碼版本。
圖 2：GitOps 工作流程
如果您已經通過功能分支使用了??Git 流程系統(tǒng)??的拉取請求特性，那么您無需在 GitOps 的新流程上投入太多。此外，由于您的基礎設施(和其他操作)也被定義為代碼，您將能夠實施相同的代碼審查實踐。
獨立的構建和部署流程(CI 和 CD)
- CI 流程負責構建應用程序代碼并將其打包到容器鏡像中。
- CD 流程執(zhí)行使最終狀態(tài)與倉庫代碼中描述的系統(tǒng)所需狀態(tài)保持一致的自動化操作。
最終，GitOps 將 CI 和 CD 視為兩個獨立的過程——CI 是一個開發(fā)過程，而 CD 是一個操作過程。
通常用于分離這些進程的 GitOps 方法是引入另一個 Git 倉庫作為中介者。此倉庫包含有關環(huán)境的信息，并且每次提交都會觸發(fā)部署過程。另外會有一個組件，稱為操作器，位于管道和編排工具之間。該操作器會不斷將環(huán)境倉庫中的目標狀態(tài)與部署的基礎設施中的實際狀態(tài)進行比較，如果操作器檢測到任何更改，它就會更改基礎設施以匹配環(huán)境倉庫。此外，它還監(jiān)控鏡像倉庫以識別要部署的鏡像的新版本。這樣，CI 過程永遠不會觸及底層基礎設施(例如，Kubernetes 集群)。
圖 3：基于拉取的 GitOps 部署
將構建管道與部署管道解耦是針對錯誤配置的強大保護，這樣做有助于實現更高的安全性和合規(guī)性。
結論
GitOps 作為一種運營模型，使用了許多團隊都知道的 DevOps 實踐。使用 GitOps，您可以自動化基礎設施配置過程，并將 Git 用作基礎設施配置變更的單一事實來源。因此，要創(chuàng)建成功的 GitOps 模型，您需要對環(huán)境進行聲明性定義。
如果您的團隊中也有拉取請求工作流程，那就最好不過了。為了能夠在基礎架構代碼上進行協(xié)作并創(chuàng)建操作更改，您應該提交一個拉取請求。隨后，高級 DevOps 工程師和安全專家會審查該拉取請求以驗證更改并在一切正常的情況下將它們合并到主分支中。
對于完整的 GitOps 實施，您需要 CI/CD 自動化設置參數并配置底層環(huán)境以及部署定義的代碼。
最后，公司內部應該有一種支持性的組織文化。根據我們的經驗，GitOps 方法很自然地形成了一種結構，在這種結構中，開發(fā)人員將會受益于自助服務基礎設施資源自動化的增長，而平臺工程師則可以在組織中扮演更有影響力的角色。這將是一種雙贏的方法，使團隊中的每個人都更團結一致，感到充實。
譯者介紹
崔瑩峰，51CTO社區(qū)編輯，一名70后程序員，擁有10多年工作經驗，長期從事 Java 開發(fā)，架構設計，容器化等相關工作，精通Java，熟練使用Maven、Jenkins等Devops相關工具鏈，擅長容器化方案規(guī)劃、設計和落地。
原文標題：??3 Steps to Developing a Successful GitOps Model??，作者：Marija Naumovska
