極狐GitLab|雲原生時代，關於GitOps你知道多少？

GitOps這個詞出現於2017年，是由Weaveworks公司根據多年雲端計算基礎設施和應用程式管理經驗而提出的一個概念。可以看出GitOps是非常年輕的，它的出現與雲端計算的大力推進有關，或者也可以直接點說，與雲原生有關。

雲原生是近幾年最火爆的技術熱詞之一，幾乎所有的雲端計算產品都會或多或少跟雲原生髮生關聯。關於雲原生，現在有一個大家都接受的定義：雲原生技術使企業能夠在現代動態環境中構建和執行可擴充套件的應用程式，如公有云、私有云和混合雲。容器、服務網格、微服務、不可變的基礎設施和宣告式API是雲原生的典型技術。其中，雲原生應用程式的部署是重點，因為它與GitOps密切相關。

一般情況下，我們可以使用下面的持續交付系統(示意圖)來完成雲原生應用程式的部署與交付。

上述模式屬於“push”模式，這是一種很常用的模式，很容易實現一鍵式部署。但是也存在一些問題，就是沒法保證倉庫清單(包括配置倉庫和映象倉庫)和叢集側的實際情況相一致，叢集側的實際情況沒法準確地在叢集側體現出來。長此以往，很容易發生“配置漂移”及安全合規問題。而想要解決這個問題，我們可以藉助GitOps來實現。

關於GitOps有這麼幾個特性：以宣告式系統(包括基礎設施和應用程式)為基座(典型如Kubernetes)；以Git(典型如極狐GitLab)為單一可信源；一切皆程式碼(應用程式 & 基礎設施)。所以使用GitOps後，上述的“push”模型就變為了下面的“pull”模型：

“Pull”模型的關鍵就是：單一可信源(如極狐GitLab)與Kubernetes叢集的整合，當可信源側的檔案清單發生變更的時候，叢集側能夠及時捕捉到此變更，從而完成變更清單的部署。而極狐GitLab Kubernetes  Agent正是為了解決這個問題而誕生的。極狐GitLab Kubernetes Agent 有兩部分組成：位於叢集側的極狐GitLab Kubernetes Agent(agentk)和位於極狐GitLab側的極狐GitLab Kubernetes Agent Server(GitLab-KAS)，能夠很好的完成上述的GitOps Workflow。

而想要實現GitOps的實踐，則需要基礎設施即程式碼(Infrastructure as Code，簡稱 IaC)、Merge Request(MRs)、CI/CD三叉戟的組合拳。
基礎設施即程式碼(IaC)

基礎設施即程式碼是一種基於使用軟體開發實踐來進行基礎設施自動化管理的方法。它強調透過一致的、可重複的程式來對基礎設施系統進行修改。當需要對基礎設施進行修改時，只需要修改於基礎設施相關的程式碼即可，隨後會有自動化來測試這些變更並最終將這些變更應用到基礎設施系統中。

GitOps的重要特性之一就是：一切皆程式碼。以Git為單一可信源，所有與軟體開發相關流程中的程式碼(包括基礎設施程式碼、應用程式原始碼、配置等)都會儲存在Git倉庫中。

極狐GitLab很好的與基礎設施即程式碼中的瑞士刀——Terraform做了整合，可以方便的完成雲基礎設施的自動化管理。所有管理過程都是透過合併請求(Merge Request)來完成的，當需要對基礎設施作某些變更時，只需要修改程式碼，並提交MR，在所有的修改都被審查和批准後，程式碼可以被合併到主分支上。一旦程式碼變化被合併，所有的變化將被部署到生產中。

Merge Request(MR)

當開發或者運維想要對系統(基礎設施或者應用程式)做出某些變更時，需要提一個Merge Request，這是一種讓多人、多團隊進行協作的方式，能更好的對變更進行評審(Review)，提前評估變更的必要性、準確性、安全性等，從而降低變更給系統帶來的風險。對系統所有的變更發起點都是程式碼變更，這樣就使安全審計變得簡單，因為一切皆程式碼，所見即所得，評審、審批都在倉庫系統中，對於所有人員都是透明可見的，透明度也會增強團隊成員之間的信任度和協作性。
CI/CD

當MR建立稽核完畢，後續的變更需要CI/CD自動化的流程去完成系統的變更。自動化的流程減少了人為的手動干預，減少了人員誤操作所帶來的風險，同時能夠節省時間，在大規模使用場景中，是非常重要的一環。

總的來說，GitOps讓所有變更的發起和應用都聚焦在極狐GitLab倉庫中，開啟了雲原生時代基礎設施管理和應用程式持續交付的新篇章。GitOps能夠帶來“快速進行變更更新和回滾”、“人員工作體驗的提升”、“安全性提高”、“合規審計容易做”等好處，但同時也存在著一些挑戰，諸如“協作文化的建立”、“敏感資訊的處理”、“Git Workflow的建立”等問題，但隨著技術的發展，我們相信，這些困難也會被一一攻克的。