【51CTO.com快譯】如今，許多團隊都在各種項目中爭相使用著諸如：版本控制、代碼審查、以及CI/CD管道等，與DevOps有關的優秀實踐。不過，您是否注意到，這些方法主要針對的是軟件開發生命周期中的自動化。而在涉及到基礎架構的設置和部署時，項目團隊仍然主要依賴的是手動的過程。

[[355786]]

對此，GitOps提供了一套管理基礎架構的自動化方法。項目團隊可以借助GitOps，并通過使用各種聲明文件，將基礎架構編寫為代碼(infrastructure as code，IaC)，進而自動化配置的過程。也就是說，我們可以像存儲應用程序的開發代碼那樣，將基礎架構存儲放在Git存儲庫中，以提高整體的交付能力和產品質量。

GitOps的工作原理

GitOps的概念最初是由Kubernetes管理公司--Weaveworks(請參見https://www.weave.works/)提出的。眾所周知，基于容器的應用往往比較復雜，而且難以進行配置和管理。因此，GitOps主要針對的是：在Kubernetes背景下，如何將編排平臺轉換到運行在容器中的微服務上，并采用DevOps領域的成熟技術，來協助簡化該過程。下面我們將深入討論GitOps的各個主要組成部分：

基礎架構即代碼(IaC)

如前所述，IaC可以通過將各種聲明性文件存儲為代碼，進而實現基礎架構的配置和管理。據此，通過利用IaC和版本控制，項目團隊可以優化當前的各項操作進程。此處提到的聲明式(Declarative)，意味著您的配置將不再是一組命令，而是對某種預期狀態的聲明。例如，在Kubernetes中，您可以在清單文件(manifest)中定義服務所需的Pod數量。系統將通過自行處理，獲取所需的容器編號，而無需工程師額外編寫命令腳本。

在此，任何符合聲明性模型的云原生軟件，都可以被視為代碼。通常，我們會將各種所需的狀態聲明為代碼，并通過系統應用的更改，以自動化的方式實現目標狀態。例如：我們可以使用諸如AWS CloudFormation之類的聲明性工具，來編寫AWS的基礎架構。

拉取請求(Pull Requests)

GitOps概念背后的主要思想是：版本控制系統是唯一的來源。我們既可以將Git用作應用代碼的變更管理系統，通過拉取請求來實現各項操作性的變更，又可以將其用于基礎架構的代碼上，以便將整個聲明文件集中于一處。

在應用開發的工作流中，我們需要將某個主分支作為發布分支。在此基礎上，開發人員會從主分支處創建各個功能性分支，以便開發出特定的功能或故事線。而在功能性分支上，一旦完成了更改，他們會通過創建拉取請求的方式，重新合并回主分支。這樣一來，我們就可以在方便實現協作的同時，透明地獲悉到誰在何處進行何種更改。而且，由于所有更改都是在Git處被提交的，因此這對于開發團隊從根本原因處進行問題的跟蹤，也是非常實用的。

可見，創建拉取請求的好處在于，我們可以讓代碼在被集成到代碼庫的另一個分支之前，事先經歷代碼的審查過程。而代碼審查恰好能夠阻止各種不良的代碼，進入測試或生產環境。顯然，這對于故障的消除，以及基礎架構代碼而言，都是非常重要的。

Git的組成

GitOps并不依賴于任何工具或技術。它可以與諸如：GitHub、BitBucket或GitLab等，任何基于Git的系統協同使用。

而在部署過程中，GitOps至少需要兩個存儲庫，即：包含了應用源代碼、及其部署清單的應用程序存儲庫;和使用著每個環境的聲明性規范描述的，包含了整個系統目標狀態的環境配置存儲庫。您可以在代碼存儲庫中將目標環境定義并描述為開發環境、測試環境、生產環境、或是包含了運行著特定版本的應用和基礎架構服務的環境。

CI/CD

要實現完整的GitOps，您勢必需要一個CI/CD管道，以實現Git存儲庫在每次發生更改時，開發團隊都能將對應的基礎架構變更交付到指定的環境中。該自動交付管道能夠將Git的拉取請求連接到編排系統中，以便通過請求來觸發管道，并讓編排系統執行指定的任務。

一般而言，GitOps有兩種可能的部署策略：推送管道和拉取管道。您可以根據當前架構需要部署的實際環境，在兩者間做出選擇。下面我們來具體看看兩種策略的各種特點：

推送管道(Push Pipelines)

目前，許多流行的CI/CD工具都在使用這種策略。開發人員通常將應用程序的源代碼、及其部署清單存儲在一個存儲庫中。當應用代碼發生變更時，管道將觸發容器映像的構建，并將變更推送到相應的環境中。由于該策略支持任何類型的基礎架構，因此它具有較大的靈活性。不過，其缺點是：它會賦予CI/CD工具對于目標環境的寫入權限。

基于推送的DevOps部署

拉取管道(Pull Pipelines)

在開發者社區中，人們普遍認為：對于GitOps的拉取管道方法是一種更安全的策略。這種方法引入了操作符(operator)的概念。它是管道和業務流程工具之間的組件。操作符能夠不斷將環境存儲庫中的目標狀態，與已部署的基礎架構的實際狀態，進行比較。如果操作符檢測到任何修改，那么它就會更改基礎架構，以適應環境存儲庫。同樣地，它也可以監視鏡像注冊表，以識別出需要部署的鏡像新版本。

基于拉取的DevOps部署

可見，在GitOps中，只有在環境存儲庫中出現修改時，對應的環境才會更新。相反，如果已實施的基礎架構在環境存儲庫中并未定義任何方式的修改，那么系統將會自動還原。

在實際項目中，大多數應用程序都會同時涉及到多個環境。對此，GitOps允許您創建多個管道，以同時更改多個環境存儲庫。當然，您也可以在環境存儲庫中使用單獨的分支，來管理多個環境。我們既可以通過將操作符部署到生產環境中，來對單個分支的修改及時做出反應，又可以通過部署到測試環境中，來響應另一個分支。

GitOps的優勢

由于GitOps專注于Git工作流、IaC、CI/CD管道，不可變服務器(immutable servers)、跟蹤、以及可觀測性等優秀實踐模型，因此它代表了對于Kubernetes云原生應用管理的高級狀態。據此，開發團隊可以從如下方面受益：

簡化持續部署

顧名思義，持續部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味著更快、更頻繁的部署。通過GitOps，部署操作符提供了必要的結構和自動化，而且這一切都在版本控制系統中發生，因此我們無需各種工具，便可管理系統的狀態、停機時間、上游/下游依賴關系、以及其他與組織相關的流程。

此外，GitOps不但提高了項目團隊的生產率，而且加快了他們的平均部署時間(Mean-time-to-deployment，MTTD)。有證據表明，自動化持續部署能夠確保團隊每天觸發30到100次以上的變更，并將生產環境的性能平均提高2到3倍。

縮短平均修復時間(Mean-time-to-repair，MTTR)

MTTR是衡量DevOps團隊績效的一項關鍵指標(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系統中的所有修改，并且能夠實現自動化的管理，因此，開發團隊能夠全面了解目標環境中的變化，輕松發現和修復錯誤，從而顯著降低MTTR。

簡化Kubernetes管理

在無需透徹了解Kubernetes的情況下，開發人員可以使用Git等較為熟悉的工具，更加輕松地管理Kubernetes的升級和各項功能。據此，新加入的成員也能夠在幾天時間快速上手Kubernetes。

全面掌握并標準化工作流

由于GitOps提供了一站式的應用程序、軟件、以及針對Kubernetes修改的框架，因此開發團隊可以清晰地洞悉整個項目的端到端工作流，并能通過Git來完全復現日常的業務運營活動。

GitOps的實現

• 建立穩定的代碼審查與測試過程。通過仔細地檢查代碼的更改，我們能夠及時發現諸如全局變量的添加等操作，并且可以通過提交拉取請求(而非直接提交更改的方式)，來驗證代碼。而在拉取請求被檢查與合并之后，管道才會被觸發。此舉在避免發布錯誤的代碼的同時，有效地保持了高標準的代碼，以及系統后續的穩定性。
• 持續測試。合并到GitOps中，往往意味需要通過高級的自動化機制，對待發布的應用程序進行徹底的測試。有了GitOps，我們不但能夠相對輕松地實現回滾，還能夠通過良好的測試用例，保障代碼的質量和可靠性。
• 專注監控。GitOps允許開發人員重復各項操作流程，改進、發布并回顧各種可追溯的系統狀態。而通過專注于監控，我們可以識別并防止任何意外的漂移(drift)、以及系統配置的變更。因此，在開始使用GitOps之前，開發團隊有必要檢查自己的監控水平，以及處理變更的能力。
• 擁抱文化。作為目前在開發領域的優秀戰略，DevOps文化能夠促進團隊的共同協作，更有效地管理基礎架構的穩定性，更快、更流暢地執行應用程序。而GitOps又能夠讓我們在此基礎上，進一步理解開發和運營的協同價值，提供一整套自動化的管理方法。

小結

作為一種非常好的工作流模式，GitOps不但可以幫助我們有效地處理云基礎架構，還能夠為工程團隊提供：更好的協調性、透明度、穩定性、以及系統耐用性等方面的諸多好處。

原文標題：GitOps – DevOps for Infrastructure Automation，作者：Sara Miteva

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】