GitOps提供了一種自動化的管理基礎架構的方法。它通過使用許多團隊已經使用的DevOps最佳實踐來做到這一點，例如版本控制，代碼審查和CI/CD管道。

由于DevOps具有提高生產力和軟件質量的巨大潛力，因此公司一直在采用它。在此過程中，我們找到了使軟件開發生命周期自動化的方法。但是，當涉及到基礎架構的設置和部署時，它仍然主要是手動過程。

借助GitOps，團隊可以自動化基礎架構的配置過程。這是由于可以使用聲明文件將基礎結構編寫為代碼(IaC)。我們可以將它們存儲在Git存儲庫中，就像存儲應用程序開發代碼一樣。

GitOps如何工作?

GitOps概念最初由Kubernetes管理公司Weave w orks提出。因此，圍繞GitOps的討論主要是在Kubernetes的背景下進行的。向在容器中運行的微服務的轉變帶來了對業務流程平臺的需求?；谌萜鞯膽贸绦蚩赡芎軓碗s，并且難以進行供應和管理。GitOps通過應用DevOps世界中成熟的技術來幫助簡化此過程。

如今，這個想法已成為DevOps愛好者的青睞，代表了IaC概念的升級模型。它圍繞三個主要組成部分：

• 基礎架構即代碼
• 拉取要求
• CI/CD

讓我們分別看看它們。

基礎架構即代碼

IaC是作為聲明文件(存儲為代碼)來配置和管理基礎結構的一種做法。通過利用IaC和版本控制團隊，可以優化所有操作程序。

GitOps圍繞IaC的聲明式模型。這就是為什么Kubernetes是實現的一個很好的例子。聲明式意味著配置更多是對預期狀態的聲明，而不是一組命令。例如，在Kubernetes中，您可以在清單中定義服務所需的Pod數量。然后，系統將自行處理。無需工程師編寫命令腳本即可獲得所需的容器編號。

任何符合聲明性模型的云原生軟件都可以視為代碼。我們使用AWS CloudFormation(一種聲明性工具)編寫AWS基礎架構。這意味著我們可以將基礎架構本身視為代碼。將所需狀態聲明為代碼。系統應用更改以自動實現該狀態。

話雖如此，聲明性模型并不是必須在GitOps中受益。您也可以在命令式定義的環境中執行操作。

拉取要求

GitOps概念背后的主要思想是版本控制系統是真實的唯一來源 。我們將Git用作應用程序代碼的變更管理系統。我們也可以將其用于基礎結構代碼。因此，整個聲明文件集都位于一個可以協作的地方。這使我們能夠使用Git的關鍵概念-對操作更改的Pull 請求。

在應用開發工作流程中，我們使用一個主分支作為發布分支。開發人員從主分支創建功能分支。開發特定功能或故事，完成后創建Pull 請求以將其合并回主分支。相同的方法對于基礎結構代碼很方便。

創建拉取請求可使代碼在集成到代碼庫的另一個分支之前，先經過代碼審查過程。代碼審查阻止不良代碼進入測試或生產環境。這對于基礎結構代碼而言甚至更為重要。通過代碼審查獲得正式批準對審核和故障排除很有幫助。

Git組織

GitOps中的部署過程至少需要兩個存儲庫：應用程序存儲庫和環境配置存儲庫。第一個包含應用程序的源代碼及其部署清單。第二個包含使用每個環境的聲明性規范描述的整個系統的期望狀態。您可以在代碼存儲庫中將環境描述為開發，測試，生產環境，其中包含可以在該環境的特定版本中運行的應用程序和基礎結構服務。

對于基礎設施，主分支可以代表一個環境。我們可以在功能分支中實現更改。然后創建一個拉取請求以合并主分支中的更改。這樣一來，我們就可以實現協作，同時對誰進行了哪些更改保持透明。由于所有更改都是在Git中提交的，因此這對于從根本原因進行問題跟蹤也很有用。

GitOps可與任何基于Git的系統一起使用，例如GitHub，BitBucket或GitLab。它不依賴于任何工具或技術。

CI/CD

要實現完整的GitOps實施，您需要一個CI/CD管道。借助自動交付管道，每次Git存儲庫中發生更改時，您都可以將基礎結構更改交付到指定的環境。這里有管道將您的Git pull請求連接到業務流程系統。當您通過拉取請求觸發管道時，業務流程系統將執行任務。

GitOps部署策略有兩種可能性：推和拉管道。它們之間的區別在于您確保部署環境類似于所需基礎結構的方式。

推管道

許多流行的CI/CD工具都在使用這種策略。我們將應用程序的源代碼及其部署清單存儲在一個存儲庫中。當應用程序代碼中發生新更新時，構建管道將觸發。管道構建容器映像并將更改推送到環境。該策略可支持任何類型的基礎架構，因此帶來了更大的靈活性。缺點是它使CI/CD工具可以寫入您的環境。

基于推送的GitOps部署

拉管道

社區認為對于GitOps，拉管道方法是一種更安全的做法。通過這種方法，引入了操作員。操作員是管道和業務流程工具之間的組件。它不斷將環境存儲庫中的目標狀態與已部署的基礎架構中的實際狀態進行比較。如果操作員檢測到任何更改，便會更改基礎結構以適合環境存儲庫。同樣，可以監視映像注冊表以識別要部署的映像的新版本。這就是GitOps如此特別的原因。

基于拉式的GitOps部署

在GitOps中，僅當環境存儲庫中有更改時才進行環境更新。如果已實施的基礎架構以環境存儲庫中未定義的任何方式更改，則系統將還原所做的任何修改。

對于大多數應用程序，您可能需要多個環境。GitOps允許您創建可以更改環境存儲庫的多個管道。您可以在環境存儲庫中使用單獨的分支來管理更多環境。操作員可以通過部署到生產來對一個分支的更改做出反應，而可以通過部署到測試來對另一個分支進行響應。

GitOps有什么好處?

使用DevOps最佳做法

由于GitOps是專注于Git工作流，IaC，CI/CD管道，不可變服務器，跟蹤和可觀察性的現有最佳實踐的模型，因此它代表了Kubernetes的云原生應用程序管理的更高級狀態。因此，公司現有的體系和經驗可以為您提供很多幫助。

持續部署-簡化

持續部署意味著更快，更頻繁地部署。由于各種考慮因素，例如系統的狀態，停機時間的阻力，上游/下游的依存關系以及許多其他組織相關的流程和依存關系，正確的連續部署一直是非常具有挑戰性的。

GitOps允許您執行此操作，而無需管理大量工具，因為一切都發生在版本控制系統中。由于部署操作員，它提供了結構和自動化。

這也提高了生產率并加快了MTTD(平均部署時間)。自動連續部署可確保團隊每天發送30-100倍以上的變更，從而將平均生產性能提高2-3倍。

較低的MTTR(平均修復時間)

MTTR是DevOps團隊應衡量的關鍵指標之一。在微服務體系結構中，即使是很小的問題也很難修復。由于GitOps保留了版本控制系統中的所有更改，并且管理是自動化的，因此可以顯著降低MTTR。您可以全面了解環境如何發生變化，錯誤恢復變得非常容易。

簡化的Kubernetes管理

在不完全了解Kubernetes的情況下，開發人員可以使用熟悉的工具(如Git)更輕松地處理Kubernetes升級和功能。新嵌入的開發人員將輕松上手，并在幾天而不是幾個月內活躍起來。

改善了整個公司的標準化

您擁有貫穿整個企業的透明的端到端工作流程，因為GitOps具有一個用于渲染應用程序，軟件和Kubernetes附加修改的框架。Git還可以完全復制您的運營活動。

如何準備GitOps?

• 建立穩定的代碼審查和測試過程仔細檢查代碼更改可能會指出一些明顯的操作，例如添加全局變量。它可以防止錯誤代碼被釋放。然后，您可以通過請求提交經過驗證的代碼，從而使開發人員無法直接提交任何更改。查看并合并拉取請求后，即可觸發管道。這是保持高標準代碼和后續系統穩定性的第一步。
• 測試，測試，測試集成GitOps意味著具有高級自動化，需要對發布的應用程序進行徹底的測試。即使GitOps允許您相對輕松地回滾，釋放經過良好測試用例的良好代碼也可以使您的過程更加可靠。
• 專注于監控GitOps允許可重復的操作流程，可追溯系統狀態的改進，推出和回滾。仔細的監視可以幫助您識別并防止任何意外的漂移和系統配置更改。因此，在開始使用GitOps之前，請復查您的監視技能，并以他們可以處理此更改的方式來增強它們。
• 擁抱文化具有較長發布時間的常規流程限制只能使您退縮。擁有DevOps文化意味著運用最佳戰略，這將幫助團隊理解開發和運營行動的價值。同時，他們必須共同協作以創建整體穩定的基礎架構，更快速，更流暢地執行應用程序以及有效地管理系統。缺乏DevOps文化會阻止您享受GitOps的好處。

為什么選擇GitOps?

GitOps是一種非常好的工作流程模式，可以幫助您有效地處理云基礎架構。GitOps可以為工程團隊提供眾多優勢，包括更好的協調性，透明度，穩定性和系統耐用性。

原文地址：https://mp.weixin.qq.com/s/r8yMHXTa6Uhyt52xsk5PAw