[[330020]]

【51CTO.com快譯】

英國作家Aldous Huxley曾說：“速度是真正的樂趣之源。”我認為生活如此，軟件領域亦然。隨著DevOps以及GitOps之類輔助實踐的興起，軟件從架構設計到代碼被部署到生產環境的速度是越來越快。

實際上，DevOps是通過定義一組實踐和文化的轉變，來提高我們生成代碼的速度，并保證代碼的可靠性。DevOps本身只是一個廣義術語，不同的組織和團隊在其核心原理上開發出了各種具體的實踐，其中包括：ChatOps、DevSecOps、AIOps、以及一種稱為GitOps的較新的實踐。

GitOps的出現和興起，主要得益于軟件開發行業對于Kubernetes的廣泛采用。在各類組織向Kubernetes的邁進過程中，開發團隊的逐步成長，以及對于擴展集群的管理實踐會變得勢在必行。因此GitOps旨在將Git和Kubernetes結合在一起，為開發人員提供某種形式的操作模型、以及基于Kubernetes的基礎架構和應用程序。可以說，在Kubernetes開發的過程中，GitOps能夠在確保“速度”的基礎上，實現軟件方案的持續交付。

下面，我們來看看GitOps的工作原理，它的啟動與運行，以及如何在Kubernetes中配合使用GitOps，以團隊的DevOps體驗。

工作原理

GitOps秉承了DevOps的核心理念--“構建它并交付它(you built it you ship it)”。它能夠讓開發人員在自己所選的Git工具中，提出拉式請求，觸發Kubernetes集群的部署，從而使得Git成為唯一的來源。

顯然，該思想是將基于推式的管道替換為基于拉式的管道，從而使得開發人員能夠直接根據其拉式請求執行部署。而一旦開發人員執行合并或打開請求，該基礎結構就會在部署過程中觸發一系列的事件。GitOps運算符(operator)只要檢測到此類變化，就會導致另一個運算符聲明的更改，并將其部署到集群之中。例如，您可以使用如下工具棧來實現GitOps：

• 將Bitbucket作為您的Git VCS(譯者注：Version Control System，版本控制系統)工具。
• 用Docker存儲您的各種鏡像。
• 用Amazon S3來存儲各種Helm圖表。
• 用AWS Lambda拉取圖表，并提交給集群存儲庫。
• 用Weaveworks Flux檢測集群存儲庫中的更改，并做相應的調整。

當然，在您的工具棧中，實現此類功能的實際基礎架構可能會有所不同，但是其機制卻是相似的。

如下是可以實現的GitOps工作流：

• 使用Bitbucket管道之類的CI(持續集成)工具，將各種Docker鏡像推送到Quay之類的托管(hosting)工具處。
• 各種云功能函數從主存儲bucket處，將不同的配置和helm圖表復制到主git存儲庫中。
• 諸如Weaveworks Flux之類的GitOps運算符，會根據各種配置圖表去更新集群，并通過Lambda函數提取不同的helm圖表。

當然，上述技術棧中所描述的每個工具都有著對應的替代方案，開發團隊可以選擇最適合的工具，以實現DevOps的目標。例如，同屬于Atlassian套件的Jira功能就能夠輕松地與Bitbucket協同發揮作用。因此，如果一個拉式請求在Bitbucket中被創建，就會自動將Jira中的問題發送到自定義的“部署”上。這將大幅簡化從設計到發布的DevOps實踐過程。

類似地，當考慮到通過GitOps實現的持續交付機制可能出現失敗時，我們可以添加其他的監控工具，以提供急需的可見性。例如，Thundra.io可被用于監控S3觸發的AWS Lambda函數，以確保在將更改提交給集群存儲庫時，不會發生任何故障。

同理，我們也可以利用Thundra.io的集成功能，將警報發送給Opsgenie之類的報警工具，進而通知合適的值班人員，以快速解決那些由拉式請求觸發的部署所引發的任何問題。

可見，我們完全可以通過向GitOps引擎添加更多的功能，以提高GitOps實踐過程中的可靠性和便利性。

給帶來的Kubernetes的便利性

總的說來，GitOps能夠為Kubernetes的部署提供融合、冪等、確定性和自動化等方面的功能。根據Kubernetes強大的收斂機制，它將不斷嘗試去改變集群的狀態，讓各種收斂應用都具有相同的結果。而且這些都會自動而迅速地被觸發。

Kubernetes的編排器(orchestrator)會持續將各種更改應用到集群中，直到集群收斂到配置更新所定義的狀態為止，也就是要滿足開發人員或SRE人員所期望的配置狀態。這不但適用于所有的Kubernetes資源，還能夠被用到自定義資源(Custom Resource Definitions，CRD)或Kubernetes的擴展。

整個GitOps的過程始于在Git存儲庫中定義某個所需的狀態，然后Git被定位為唯一的來源。此外，我們需要保障提交過來的更改能夠與群集相配，以便標記處群集是已經收斂到了所需的狀態，還是已偏離了該狀態。

當期望狀態與實際狀態不相同時，Kubernetes中的收斂運算符會主動嘗試著補足這兩個狀態之間的差異，即：根據那些針對Git的提交，觸發更改的“差異”警報，以標識處仍然需要進一步的收斂。因此，這就意味著，所有的提交都會產生對于集群的可驗證的、且冪等的更改。當然，Kubernetes也可能按需產生回滾。就其機制而言，回滾可以被看作是進一步收斂到以前的狀態。

最后，如果系統中不再存在“差異”警報、或僅存在“聚合”警報，那么該機制就認為實際狀態已經達到了所需的狀態。實際上，我們可以使用回調、或回寫事件的方法，來設置此類聚合狀態。

至此，我們可以認識到：GitOps依賴于IAC(譯者注：基礎架構即代碼)的概念。即：以編程的方式定義了基礎架構，而基礎架構的實際狀態也會隨著發生相應的變化。這種就是我們在前文中提到的基于拉式的部署方式，它與傳統的基于推式的部署有所不同。

相關工具

如您所知，DevOps是一個廣闊的領域，它不僅僅限于軟件行業。而GitOps則只是在軟件行業朝著更加敏捷、可靠的方向發展過程中，一種新興的開發實踐。更準確地說，隨著技術趨勢的變化，開發實踐必須適應可用的技術，而GitOps是團隊和組織如何跟蹤技術發展，持續推進開發實踐的一種優秀示例。值得一提的是，諸如Weaveworks Flux之類的運算符，可以很好地幫助您在集群啟用GitOps。當然，您也可以選用Spinnaker之類的其他代替方案。

此外，考慮到持續部署可能會給生成環境帶來風險，我們可以通過添加諸如Thundra.io和Opsgenie之類的工具，來對系統進行全覆蓋性的測試，以減少風險點，保證一定的可觀察性和事件管理能力。

總結

總的來說，我們可以將GitOps視為一種實踐，它能夠利用Kubernetes的核心力量，來加快軟件從設計到發布的全部過程。我們只有掌握了GitOps的工作原理，才能充分發揮Kubernetes在容器服務方面的巨大潛力，為持續部署與持續交付保駕護航。

原標題：Under the Hood of GitOps  作者： Sarjeel Yusuf

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