GitOps是如何運作的？

GitOps的概念最初是由Kubernetes管理公司Weaveworks提出的。所以關於GitOps的討論主要是在Kubernetes的背景下進行的。向在容器中執行的微服務的轉換帶來了對編排平臺的需求。基於容器的應用程式的供應和管理可能很複雜，也很困難。GitOps透過應用已在DevOps世界中驗證過的技術來幫助簡化這一點。

如今，這個想法在DevOps的愛好者中很流行，代表了IaC概念的升級模型。它圍繞三個主要部分展開：

基礎設施即程式碼

拉取請求

CI/CD

基礎設施即程式碼

IaC是一種將基礎設施作為宣告檔案（儲存為程式碼）提供和管理的實踐。透過利用IaC和版本控制團隊可以最佳化所有的操作過程。

GitOps以IaC的宣告式模型為中心。這就是為什麼Kubernetes是一個很好的實現示例。宣告性意味著配置更多的是對預期狀態的宣告，而不是一組命令。例如，在Kubernetes中，您可以在清單中定義服務所需的pods數量。系統會自行處理。工程師不需要編寫能夠達到所需pod編號的命令式指令碼。

任何符合宣告式模型的雲本地軟體都可以被視為程式碼。我們使用AWS CloudFormation來編寫AWS基礎設施，這是一個宣告性工具。這意味著我們可以將基礎設施本身視為程式碼。將所需狀態宣告為程式碼。系統應用變更來實現自動化狀態。

話雖如此，宣告式模型在GitOps中並不是必須的。命令式定義的環境也可以這樣做。

拉取請求

在應用程式開發工作流中，我們使用一個主分支作為釋出分支。開發人員從主分支建立功能分支。開發一個特定的特性或故事，完成後建立一個pull請求，將其合併回主分支。同樣的方法對於基礎結構程式碼也很方便。

在我們將程式碼整合到程式碼基的另一個分支之前，建立一個pull request使程式碼能夠經過一個程式碼審查過程。程式碼檢查可以阻止壞程式碼進入測試或生產環境。這對於基礎架構程式碼甚至更為重要。透過程式碼審查獲得正式的批准對審計和故障排除有很大幫助。

Git組織

GitOps中的部署過程至少需要兩個repo：應用程式repo和環境配置repo。第一個包含應用程式的原始碼及其部署清單。第二個包含對每個環境使用宣告性規範描述的整個系統的期望狀態。您可以將您的環境描述為程式碼儲存庫中的開發、測試、生產，其中包含可以與該環境的特定版本一起執行的應用程式和基礎設施服務。

在基礎設施的情況下，主要分支可以表示一個環境。我們可以在特性分支中實現變更。然後建立一個pull request來合併主分支中的更改。透過這種方式，我們可以實現協作，同時對誰執行了哪些更改保持透明。這也有利於問題跟蹤到根源，因為所有更改都是在Git中提交的。

GitOps可用於任何基於Git的系統，如GitHub、BitBucket或GitLab。它不依賴於任何工具或技術。

CI/CD

要實現完整的GitOps，您需要一個CI/CD管道。使用自動交付管道，每次Git儲存庫中發生更改時，您都可以將基礎結構更改傳遞到指定的環境中。這裡的管道用於將Git pull請求連線到編排系統。當您使用pull請求觸發管道時，業務流程系統將執行該任務。

GitOps部署策略有兩種可能:push管道和pull管道。它們之間的區別在於確保部署環境與所需的基礎設施相似的方式。

Push管道

許多流行的CI/CD工具都在使用這種策略。我們將應用程式的原始碼及其部署清單儲存在一個儲存庫中。當應用程式程式碼中發生新的更新時，生成管道將觸發。管道構建容器映像並將更改推送到環境中。這種策略帶來了更大的靈活性，因為它可以支援任何型別的基礎設施。缺點是它允許CI/CD工具訪問您的環境。

基於push的DevOps部署

社群認為Pull管道方法對GitOps來說更安全的實踐。透過這種方法，引入了運算子。運算子是管道和編配工具之間的一個元件。它不斷地將環境儲存庫中的目標狀態與部署基礎設施中的實際狀態進行比較。操作員如果檢測到任何更改，就更改基礎結構以適應環境儲存庫。另外，還可以監視映像登錄檔，以確定要部署的映像的新版本。這就是GitOps如此特別的原因。

基於pull的DevOps部署

在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？

建立一個穩定的程式碼評審和測試過程。仔細檢查程式碼更改可以指出一些明顯的操作，例如新增全域性變數。它可以防止壞程式碼被釋放。然後，您可以透過pull請求提交經過驗證的程式碼，不允許開發人員直接提交任何更改。一旦請求被檢查和合並，就可以觸發管道。這是維護高標準程式碼和隨後系統穩定性的第一步。

加入GitOps意味著擁有高水平的自動化，這需要對管道釋出的應用程式進行徹底的測試。儘管GitOps允許相對容易地回滾，但釋出經過良好測試用例的好程式碼會使流程更加可靠。

重點監控

GitOps允許可重複的操作過程，改進可跟蹤的系統狀態、釋出和回滾。仔細的監視可以幫助您識別和防止配置中任何意外的偏移和系統更改。所以，在開始使用GitOps之前，回顧一下你的監控技能，並加強你的監控能力，讓他們能夠應對這種變化。

接受文化

具有長髮布時間的傳統流程約束只會阻礙您。採用DevOps文化意味著利用最好的策略，幫助團隊理解開發和運營行動的價值。與此同時，它們必須一起協作，以建立一個整體穩定的基礎設施，更快、更平穩地執行應用程式，並有效地管理系統。缺乏DevOps文化會妨礙你享受GitOps的好處。

為什麼是GitOps？

GitOps是一種非常好的工作流模式，它可以幫助你高效地處理雲基礎設施。GitOps可以為工程團隊提供許多優勢，包括更好的協調、透明度、穩定性和系統的耐用性。