前言

GitOps 的概念最初來源于?Weaveworks?的聯合創始人 Alexis 在 2017 年 8 月發表的一篇博客?GitOps - Operations by Pull Request。文章介紹了 Weaveworks 的工程師如何以 Git 作為事實的唯一真實來源，部署、管理和監控基于 Kubernetes 的 SaaS 應用。

隨后，Weaveworks 在其網站上發表了一系列介紹 GitOps 應用案例和最佳實踐的文章，對 GitOps 進行推廣。同時，市場上也出現了一批擁抱 GitOps 模式的工具和產品，如?Jenkins X、Argo CD、Weave Flux?等。而 KubeCon EU 2019 中關于 GitOps 的討論?GitOps and Best Practices for Cloud Native CICD，則讓 GitOps 進入到了更多人的視野當中。

本文將以上述資料為基礎，重點介紹如下內容：

什么是 GitOps？

推模式和拉模式

GitOps 的主要優勢

GitOps 關鍵工具

什么是 GitOps？

GitOps 是一種快速、安全的方法，可供開發或運維人員維護和更新運行在 Kubernetes 或其他聲明式編排框架中的復雜應用。

GitOps 四項原則

以聲明的方式描述整個系統

借助 Kubernetes、Terraform 等工具，我們只需要聲明系統想要達到的目標狀態，工具會驅動系統向目標狀態逼近。聲明意味著系統狀態由一組事實而不是一組指令保證，方便進行維護。當我們將聲明信息存儲在 Git 中后，系統狀態便具備了唯一的事實來源。這樣，我們可以輕松地部署和回滾應用。更重要的是，當災難發生時，群集的基礎架構也能夠可靠且快速地再現。

系統的目標狀態通過 Git 進行版本控制

通過將系統的目標狀態存儲在具有版本控制功能的系統中，并作為唯一的事實來源，我們能夠從中派生和驅動一切。

通過 pull request 發起對目標狀態的變更申請，狀態變化清晰呈現，變更 review 簡單明了。

系統的每一次變更都對應著一條 git commit，變更行為可審計。

回滾操作只需要使用git revert命令把目標狀態恢復到前一個狀態。

對目標狀態的變更批準后將自動應用到系統

一旦將聲明的狀態保存在 Git 中，下一步就是允許對該狀態的任何變更都能自動地應用于系統，這樣可以極大地提升產品交付速度。更重要的是，GitOps 采用拉模式更新系統狀態，將做什么和怎么做分開，這樣能夠更加有效地劃分出系統的安全邊界。

驅動收斂 & 上報偏離

GitOps 中包含一個操作的反饋和控制循環。它將持續地比較系統的實際狀態和 Git 中的目標狀態，如果在預期時間內狀態仍未收斂，便會觸發告警并上報差異。同時，該循環讓系統具備了自愈能力。自愈不僅僅意味著節點或 pod 失敗， 這些由 Kubernetes 處理，在更廣泛的角度，它能修正一些非預期的操作造成的系統狀態偏離。下圖展示了 GitOps 按控制論思想構建的閉環控制系統。

GitOps 的簡潔定義

進一步，可以將 GitOps 總結成以下兩點：

An operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for containerized clusters and applications.

A path towards a developer experience for managing applications; where end-to-end CICD pipelines and git workflows are applied to both operations, and development.

推模式和拉模式

本章將介紹交付流水線中的推模式和拉模式，并解釋為何 GitOps 選用拉模式來構建流水線。

CI/CD 流水線

目前大多數 CI/CD 工具都基于推模式建交付流水線。代碼被合并到主分支后會觸發 CI 系統進行構建和一系列的測試，并將新生成的鏡像推送至鏡像倉庫，最后再通過kubectl set image、helm upgrade、ksonnet apply等方式將新版本直接應用到系統，整個流程如下圖所示。

雖然這樣的方式自動化程度很高，但對它進行審視后會發現如下問題：

跨越安全邊界共享秘鑰 - 在推模式下，為了讓 CI 系統能夠自動地部署應用，需要將集群的訪問秘鑰共享給它。雖然可以通過一些措施進行防護，但畢竟還是將秘鑰暴露在了可信度較低的安全上下文中。這種做法擴大了攻擊面，會給系統帶來潛在的安全風險。

回滾操作復雜 - 如果通過 CI 任務完成一次部署后，系統出現異常，你將如何知道應該回滾到哪一個版本？你可能需要仔細查看構建日志才能找到答案。

難以快速重建集群 - 在集群完全崩潰的情況下進行重建，如何確定需要部署的每個應用的版本？你可能需要重新跑一遍 CI 任務。

GitOps 流水線

GitOps 基于拉模式構建交付流水線。此時，開發人員發布一個新功能的流程如下：

通過 pull request 向主分支提交包含新功能的代碼。

代碼審核通過后將被合并至主分支。

合并行為將觸發 CI 系統進行構建和一系列的測試，并將新生成的鏡像推送至鏡像倉庫。

GitOps 檢測到有新的鏡像，會提取最新的鏡像標記，然后同步到 Git 配置倉庫的清單中。

GitOps 檢測到集群狀態過期，會從配置倉庫中拉取更新后的清單，并將包含新功能的鏡像部署到集群里。

通過為不同的集群創建各自的子目錄或分支，可以輕松地將該模式拓展到多集群環境。

接下來讓我們看看 GitOps 流水線如何解決推式流水線中存在的那些問題。

部署在集群內部的 GitOps 模塊負責更新集群，這樣就避免了集群 API 和秘鑰的跨邊界暴露。更重要的是，流水線中每個邏輯單元的寫操作都被限定在了安全邊界以內，職責劃分清晰。

由于每一次變更都對應著一條 git commit，回滾操作只需要簡單的把目標狀態恢復到前一個狀態。

由于在 Git 的配置倉庫中保留了集群的目標狀態，如果集群完全崩潰，可以基于倉庫中的清單快速重建集群。

GitOps 的主要優勢

經過上面兩章的介紹，可以將 GitOps 的優勢總結如下：

提高生產力 - 采用集成了反饋控制循環的持續部署流水線可以大大提升新功能的發布速度。

提升開發者體驗 - 開發者可以使用熟悉的工具 Git 去發布新功能，而無需了解復雜的部署交付流程。新入職的員工可以在幾天內快速上手，從而提高工作效率。

行為可審計 - 使用 Git 工作流管理集群，天然能夠獲得所有變更的審計日志，滿足合規性需求，提升系統的安全與穩定性。

更高的可靠性 - 借助 Git 的還原（revert）、分叉（fork）功能，可以實現穩定且可重現的回滾。由于整個系統的描述都存放在 Git 中，我們有了唯一的真實來源，這能大大縮短集群完全崩潰后的恢復時間。

一致性和標準化 - 由于 GitOps 為基礎設置、應用程序、Kubernetes 插件的部署變更提供了統一的模型，因此我們可以在整個組織中實現一致的端到端工作流。不僅僅是 CI/CD 流水線由 pull request 驅動，運維任務也可以通過 Git 完全重現。

更強的安全保證 - 得益于 Git 內置的安全特性，保障了存放在 Git 中的集群目標狀態聲明的安全性。

GitOps 關鍵工具

GitOps 的概念來源于 Weaveworks，但它并沒有和特定的公司或工具綁定。下面列出了一些實現 GitOps 模式可選用的工具。

• Infrastructure as Code & Configuration as Code

  • Terraform
  • CloudFormation
  • ROS
  • Kubernetes
  • Chef
  • Ansible

• 版本控制工具

  • GitLab
  • Bitbucket

• 狀態比較工具

  • Kubediff

• 交付流水線

  • Jenkins X
  • Argo CD
  • Weave Flux
  • Spinnaker

總結

Flickr 的工程師 John Allspaw 和 Paul Hammond 在 Velocity Conf 2009 上發表的演講?10+ Deploys Per Day: Dev and Ops Cooperation at Flickr?開啟了 DevOps 時代的序幕。它是人們追求以更高的頻率發布高質量的軟件的必然產物。

進入云原生時代后，產品的基礎設施、系統架構和運維方式都發生了很大變化。為此，GitOps 對 DevOps 理念進行了擴展，它吸收了 DevOps 文化中協作、試驗、快速反饋、持續改進等思想，并以 Git 作為事實的來源和鏈接的橋梁，旨在簡化云原生時代基礎設施和應用程序的部署與管理方式，實現產品更快、更頻繁、更穩定的交付。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的GitOps 初探的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。