介紹GitOps的工作原理

本文將介紹GitOps的工作原理，它的啟動與執行，以及如何在Kubernetes中配合使用GitOps，以團隊的DevOps體驗.

英國作家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：

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

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

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

1. 使用 Bitbucket管道之類的CI(持續整合)工具，將各種Docker映象推送到 Quay之類的託管(hosting)工具處。
2. 各種雲功能函式從主儲存bucket處，將不同的配置和 helm圖表複製到主git儲存庫中。
3. 諸如 Weaveworks Flux之類的GitOps運算子，會根據各種配置圖表去更新叢集，並通過Lambda函式提取不同的helm圖表。

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

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

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

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

總的說來，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在容器服務方面的巨大潛力，為持續部署與持續交付保駕護航。

原文地址： https://www.linuxprobe.com/gitops-jieshao.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2705761/，如需轉載，請註明出處，否則將追究法律責任。