GitOps—用于基礎設施自動化的DevOps
本篇目錄
GitOps提供了一種自動化和管理基礎設施的方法。它通過許多團隊已經應用的DevOps最佳實踐來做到這一點，例如版本控制、代碼評審和CI/CD管道。
由于DevOps在提高生産率和軟件質量方面的巨大潛力，許多公司一直采用DevOps。在這個過程中，我們已經找到了自動化軟件開發生命周期的方法。然而，在基礎設施設置和部署方面，它仍然主要是一個手動過程。
使用GitOps，團隊可以自動化基礎設施配置過程。這是因爲可以使用聲明文件將基礎結構編寫爲代碼（IaC）。我們可以將它們存儲在Git存儲庫中，就像存儲應用程序開發代碼一樣。
GitOps是如何運作的？
GitOps的概念最初是由Kubernetes管理公司Weaveworks提出的。所以關于GitOps的討論主要是在Kubernetes的背景下進行的。向在容器中運行的微服務的轉換帶來了對編排平台的需求。基于容器的應用程序的供應和管理可能很複雜，也很困難。GitOps通過應用已在DevOps世界中驗證過的技術來幫助簡化這一點。如今，這個想法在DevOps的愛好者中很流行，代表了IaC概念的升級模型。
基礎設施即代碼
IaC是一種將基礎設施作爲聲明文件（存儲爲代碼）提供和管理的實踐。通過利用IaC和版本控制團隊可以優化所有的操作過程。GitOps以IaC的聲明式模型爲中心。這就是爲什麽Kubernetes是一個很好的實現示例。聲明性意味著配置更多的是對預期狀態的聲明，而不是一組命令。例如，在Kubernetes中，您可以在清單中定義服務所需的pods數量。系統會自行處理。工程師不需要編寫能夠達到所需pod編號的命令式腳本。
任何符合声明式模型的云本地软件都可以被视为代码。我们使用AWS CloudFormation来编写AWS基础设施，这是一个声明性工具。这意味着我们可以将基础设施本身视为代码。将所需状态声明为代码。系统应用变更来实现自动化状态。
話雖如此，聲明式模型在GitOps中並不是必須的。命令式定義的環境也可以這樣做。
拉取請求
GitOps概念背後的主要思想是版本控制系統是事實的唯一來源。我們使用Git作爲應用程序代碼的變更管理系統。我們還可以在基礎設施代碼中使用它。因此，整個聲明文件集都在一個可以協作的地方。這使我們能夠使用Git的關鍵概念——操作更改的pull請求。在應用程序開發工作流中，我們使用一個主分支作爲發布分支。開發人員從主分支創建功能分支。開發一個特定的特性或故事，完成後創建一個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管道
社區認爲Pull管道方法對GitOps來說更安全的實踐。通過這種方法，引入了運算符。操作符是管道和編配工具之間的一個組件。它不斷地將環境存儲庫中的目標狀態與部署基礎設施中的實際狀態進行比較。操作員如果檢測到任何更改，就更改基礎結構以適應環境存儲庫。另外，還可以監視映像注冊表，以確定要部署的映像的新版本。這就是GitOps如此特別的原因。
基于pull的DevOps部署
在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？
建立一個穩定的代碼評審和測試過程。仔細檢查代碼更改可以指出一些明顯的操作，例如添加全局變量。它可以防止壞代碼被釋放。然後，您可以通過pull請求提交經過驗證的代碼，不允許開發人員直接提交任何更改。一旦請求被檢查和合並，就可以觸發管道。這是維護高標准代碼和隨後系統穩定性的第一步。加入GitOps意味著擁有高水平的自動化，這需要對管道發布的應用程序進行徹底的測試。盡管GitOps允許相對容易地回滾，但發布經過良好測試用例的好代碼會使流程更加可靠。
重點監控
GitOps允許可重複的操作過程，改進可跟蹤的系統狀態、發布和回滾。仔細的監視可以幫助您識別和防止配置中任何意外的偏移和系統更改。所以，在開始使用GitOps之前，回顧一下你的監控技能，並加強你的監控能力，讓他們能夠應對這種變化。
接受文化
具有長發布時間的傳統流程約束只會阻礙您。采用DevOps文化意味著利用最好的策略，幫助團隊理解開發和運營行動的價值。與此同時，它們必須一起協作，以創建一個整體穩定的基礎設施，更快、更平穩地執行應用程序，並有效地管理系統。缺乏DevOps文化會妨礙你享受GitOps的好處。
爲什麽是GitOps？
GitOps是一種非常好的工作流模式，它可以幫助你高效地處理雲基礎設施。GitOps可以爲工程團隊提供許多優勢，包括更好的協調、透明度、穩定性和系統的耐用性。
原文鏈接：https://dzone.com/articles/gitops-devops-for-infrastructure-automation
