GitOps 如何改善開發人員和運維人員的日常工作?

導讀	在這篇文章中，我們將探索 GitOps 如何為基於容器化和微服務開發雲原生解決方案的組織提供最佳服務。

GitOps 是一種自動化和管理基礎設施和應用程式的模型，它透過許多團隊已經使用過的相同 DevOps 最佳實踐來完成，例如版本控制、程式碼審查和 CI/CD 管道等等。在實施 DevOps 過程中，我們雖然在軟體開發生命週期找到了自動化的方法，但在基礎設施安裝和部署方面，仍然需要手工處理。使用 GitOps，團隊可以自動化基礎設施配置過程。這得益於我們能夠將基礎架構作為程式碼 (IaC)編寫、在 Git 倉庫中對程式碼進行版本控制以及基於雲交付進行持續部署。

因為它具有提高生產力和軟體質量的巨大潛力，很多公司一直在採用 GitOps，而它也最適合開發基於容器化和微服務的雲原生解決方案的組織。

GitOps 帶來的基礎設施自動化的增長創造了為應用程式開發人員開發更具有“自助服務”方法的機會。熟練的開發人員可以使用基礎設施即程式碼來宣告他們的雲資源需求，而不是協商雲資源。這成為對基礎設施的期望狀態，集中儲存起來並可以用作程式碼中宣告的需求與執行環境的實際狀態之間的不可變參考點。

自助服務方法解放了開發人員。它讓開發人員更有效率，使他們能夠專注於創新，並讓他們的應用程式更快地推向市場。此外，它避免了開發人員和運營人員需要協商資源時可能引入的泥潭。

另一方面，經常存在一種誤解，即運營自動化程度的提高意味著運營團隊需要更少的人員，並且運營在管道中的角色正被邊緣化。我們的觀點恰恰相反;我們認為 GitOps 和內部開發平臺等現代方法為 Ops(平臺團隊)提供了振奮人心的機會，以提高他們的技能併為組織創造更多價值。在一個採用 GitOps 的高水平的雲原生軟體開發組織中，您可能會發現正是因為存在一個不斷壯大的平臺團隊才讓一切工作正常。

平臺團隊使用的實際技術可能會有所不同。在某些情況下，這可能只是一個封閉的 PaaS 解決方案。在其他情況下，它可以是建立適合組織需求的定製平臺各種工具的組合。這使他們能夠對基礎設施資源和架構施加更大的影響和控制，並建立“護欄”，以執行簡單、高效和標準化的雲原生應用程式部署方法。

GitOps 有助於改善開發人員和運營團隊之間的協作，提高他們的生產力，並增加部署頻率。它使開發人員無需瞭解底層基礎架構即可貢獻功能，從而增強了開發人員的體驗。同時，它透過程式碼審查和批准來控制操作。透過這些改進，團隊可以更快、更安全地釋出，以保持其在市場中的地位。

如果想讓公司實施的 GitOps 模型發揮最大優勢，例如整體工作流程的標準化和一致性，您需要考慮以下幾點。

宣告你的 IaC。
使用 Git 倉庫進行 IaC 開發。
將屬於應用程式程式碼生命週期一部分的實踐也複製到基礎架構程式碼中。
使用 Docker 和 Kubernetes 等技術，將您的環境、版本、配置和依賴項定義為程式碼，並確保它們在執行時得到強制執行。
逐漸將 GitOps 模型擴充套件到可以定義為程式碼的任何事物，例如安全性、策略、合規性以及基礎架構之外的所有操作。

宣告式程式碼提高了可讀性和可維護性。CloudFormation、Terraform、Pulumi 和 Crossplane 是一些可能的宣告性語言，您可以使用這些語言來定義您的基礎架構配置。

當一切都定義為程式碼時，您可以使用 Git 倉庫進行開發並探索諸如版本控制、協作和審計等內容。

一個正確的 Git 流程包括：

主分支，通常代表一個環境，如 dev、test、stage、prod 和在該環境上執行的狀態。
當開發人員需要對程式碼進行更改時，他們會從主分支建立一個新分支。
當更改準備就緒時，開發人員會建立一個拉取請求，該請求應該由運營團隊稽核以驗證和批准。安全和合規專家也可以參與此階段，正確地驗證環境的狀態。
一旦獲得批准，程式碼就可以合併到主分支並交付到測試或生產環境。
使用此工作流程，您可以跟蹤誰進行了哪些更改並確保環境具有正確的程式碼版本。

圖 2：GitOps 工作流程

如果您已經透過功能分支使用了Git 流程系統的拉取請求特性，那麼您無需在 GitOps 的新流程上投入太多。此外，由於您的基礎設施(和其他操作)也被定義為程式碼，您將能夠實施相同的程式碼審查實踐。

CI 流程負責構建應用程式程式碼並將其打包到容器映象中。
CD 流程執行使最終狀態與倉庫程式碼中描述的系統所需狀態保持一致的自動化操作。
最終，GitOps 將 CI 和 CD 視為兩個獨立的過程——CI 是一個開發過程，而 CD 是一個操作過程。

通常用於分離這些程式的 GitOps 方法是引入另一個 Git 倉庫作為中介者。此倉庫包含有關環境的資訊，並且每次提交都會觸發部署過程。另外會有一個元件，稱為操作器，位於管道和編排工具之間。該操作器會不斷將環境倉庫中的目標狀態與部署的基礎設施中的實際狀態進行比較，如果操作器檢測到任何更改，它就會更改基礎設施以匹配環境倉庫。此外，它還監控映象倉庫以識別要部署的映象的新版本。這樣，CI 過程永遠不會觸及底層基礎設施(例如，Kubernetes 叢集)。

圖 3：基於拉取的 GitOps 部署

將構建管道與部署管道解耦是針對錯誤配置的強大保護，這樣做有助於實現更高的安全性和合規性。

GitOps 作為一種運營模型，使用了許多團隊都知道的 DevOps 實踐。使用 GitOps，您可以自動化基礎設施配置過程，並將 Git 用作基礎設施配置變更的單一事實來源。因此，要建立成功的 GitOps 模型，您需要對環境進行宣告性定義。

如果您的團隊中也有拉取請求工作流程，那就最好不過了。為了能夠在基礎架構程式碼上進行協作並建立操作更改，您應該提交一個拉取請求。隨後，高階 DevOps 工程師和安全專家會審查該拉取請求以驗證更改並在一切正常的情況下將它們合併到主分支中。

對於完整的 GitOps 實施，您需要 CI/CD 自動化設定引數並配置底層環境以及部署定義的程式碼。

最後，公司內部應該有一種支援性的組織文化。根據我們的經驗，GitOps 方法很自然地形成了一種結構，在這種結構中，開發人員將會受益於自助服務基礎設施資源自動化的增長，而平臺工程師則可以在組織中扮演更有影響力的角色。這將是一種雙贏的方法，使團隊中的每個人都更團結一致，感到充實。

原文來自：