什麼是 GitOps

首先我們來了解下 GitOps：

GitOps 最早是在2017年由 Weaveworks 創立提出，它是一種進行 Kubernetes 叢集管理和應用程式交付的方式。 GitOps 使用 Git 作為宣告性基礎設施和應用程式的單一事實來源。 GitOps 的核心思想是擁有一個 Git repository，包含目標環境中當前所需基礎設施的宣告性描述，以及使目標環境與 Git repository 中描述的狀態相匹配的自動化過程。藉助 GitOps，可以針對 Git repository 與叢集中執行的內容之間的任何差異發出警報，如果存在差異，Kubernetes reconcilers會根據情況自動更新或回滾叢集。以 Git 作為 pipeline 的中心，開發人員可以使用自己熟悉的工具發出PR，以加速和簡化 Kubernetes 中應用程式部署和操作任務。

這使得 GitOps 在 Twitter 和 KubeCon 上引起了不小的轟動。

這裡說一下Weaveworks 這家公司，這是一家為開發人員提供最高效的方式來連線、觀察和控制 Docker 容器的公司。在官網上，我們能看到，GitOps 工作流的原則和模式，如何實現它們在生產中大規模執行 Kubernetes，以及GitOps 和基礎設施即程式碼 (IAC) 配置管理工具之間的區別和最佳實踐等等。https://www.weave.works/techn...

K8S的創始人之一：Kelsey Hightower 曾發推文評論過 GitOps是基於宣告式基礎設施的版本化 CI/CD，停止指令碼化操作，開始（自動化）分發。

GitOps 是如何工作的呢？

把環境配置作為 Git repository

GitOps 以程式碼庫為核心來組織部署。我們需要至少有兩個倉庫：應用程式庫和環境配置庫。應用程式庫包含應用程式的原始碼和部署應用程式的 manifests。環境配置庫包含部署環境當前所需基礎架構的所有部署manifests。它描述了哪些應用程式和基礎設施服務（訊息代理、服務網格、監控工具等）應該在部署環境中以何種配置和版本執行等內容。

基於 push 與基於 pull 的部署

兩種部署型別之間的區別在於如何確保部署環境與所需的基礎架構相同。這裡推薦，首選基於 pull 的方法，實現 GitOps 更安全、也有很多已有的最佳實踐來借鑑。

基於 pull 的部署

傳統的 CI/CD pipeline由外部事件觸發，比如新程式碼被推送到應用程式庫時，就觸發了。

而基於 Pull 的部署方法，引入了operator。它通過不斷將環境配置庫中的期望狀態與部署環境中的實際狀態進行比較來接管pipeline的角色。當發現差異時，operator會更新部署環境中的狀態以匹配環境配置庫。此外，它還可以監控 image registry ，以查詢要部署的新映象版本。

基於 pull 模型的部署不僅能做到環境配置庫更改時更新環境；

operator也能做到當實際環境與環境配置庫中存在差異時進行還原。

這就確保了所有更改都可以在 Git 日誌中進行跟蹤，因為任何人都不允許對叢集進行直接更改。

那麼，這種方式的監控點就集中在 operator 及各個元件上了（比如，映象倉庫是否能正常拉取到映象等等）。

為了避免基於 Push 場景中的上帝模式許可權問題，operator 應該始終與要部署的應用程式在同一環境或叢集中。（k8s RBAC授權：Kubernetes 從 1.6 開始支援基於角色的訪問控制機制（Role-Based Access，RBAC），叢集管理員可以對使用者或 service account 的角色進行更精確的資源訪問控制。在 RBAC 中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。）

基於 push 的部署

基於 Push 的部署策略可以利用流行的 CI/CD 工具來實現，例如 Jenkins、CircleCI 或 Travis CI。應用程式的原始碼與部署的應用程式所需的 Kubernetes YAML 一起存在於應用程式庫中。每當更新應用程式程式碼時，都會觸發構建pipeline，構建容器映象，最後使用新的部署manifest，更新環境配置庫。

也可以將 YAML 的模板儲存在應用程式庫中。構建新版本時，可以使用模板在環境配置庫中生成 YAML。

對環境配置庫的更改會觸發部署pipeline。pipeline負責將環境配置庫中的所有manifests應用到基礎設施。這就需要我們更關注部署許可權細分及控制。同時，這種方式無法自動注意到環境及其所需狀態的任何偏差。我們需要額外的監控報警方式，來保障環境與環境儲存庫中描述的內容一致。

複雜應用環境

對於大多數應用程式來說，只使用一個應用程式庫和一個環境配置庫是不現實的。GitOps 也能應對。可以設定多個構建 pipeline 來更新環境配置庫。然後就像上兩個描述過程一樣，自動化 GitOps 工作流程開始並部署應用程式。

我們需要在環境配置庫中使用獨立的分支，來管理多個環境。選擇設定 operator 或者構建pipeline，自動化 GitOps 工作流程開始並部署應用程式。

Tips：

1.不使用k8s的環境也可以考慮使用 GitOps。（目前大多數基於 pull 的 GitOps 都是在Kubernetes 下實現的。）

2.密碼。永遠不要在 git 中以純文字形式儲存密碼！在 K8s 生態系統中，有工具支援這種加密。(比如 Vault)

3.dev、qa、prod環境不能直接能用 GitOps 來處理，可以考慮引入 CI/CD pipeline 來管理環境。

4.DevOps 與GitOps 不衝突。DevOps 是關於組織中的文化變革，可以使程式設計師及系統維護者們更好地合作。而GitOps 是一種實現持續交付的技術。如果已經在推進 DevOps 那麼可能會更好接入 GitOps。

歡迎訂閱我的文章公眾號【MoeLove】

TheMoeLove

GitOps 應用實踐系列 - 綜述