| 本文將介紹GitOps的工做原理，它的啓動與運行，以及如何在Kubernetes中配合使用GitOps，以團隊的DevOps體驗. |
英國做家Aldous Huxley曾說：「速度是真正的樂趣之源。」我認爲生活如此，軟件領域亦然。隨着DevOps以及GitOps之類輔助實踐的興起，軟件從架構設計到代碼被部署到生產環境的速度是愈來愈快。html
實際上，DevOps是經過定義一組實踐和文化的轉變，來提升咱們生成代碼的速度，並保證代碼的可靠性。DevOps自己只是一個廣義術語，不一樣的組織和團隊在其核心原理上開發出了各類具體的實踐，其中包括：ChatOps、DevSecOps、AIOps、以及一種稱爲GitOps的較新的實踐。linux
GitOps的出現和興起，主要得益於軟件開發行業對於Kubernetes的普遍採用。在各種組織向Kubernetes的邁進過程當中，開發團隊的逐步成長，以及對於擴展集羣的管理實踐會變得勢在必行。所以GitOps旨在將Git和Kubernetes結合在一塊兒，爲開發人員提供某種形式的操做模型、以及基於Kubernetes的基礎架構和應用程序。能夠說，在Kubernetes開發的過程當中，GitOps可以在確保「速度」的基礎上，實現軟件方案的持續交付。git
下面，咱們來看看GitOps的工做原理，它的啓動與運行，以及如何在Kubernetes中配合使用GitOps，以團隊的DevOps體驗。github
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函數，以確保在將更改提交給集羣存儲庫時，不會發生任何故障。ui
同理，咱們也能夠利用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在容器服務方面的巨大潛力，爲持續部署與持續交付保駕護航。