GitOps 初探

前言

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 進入到了更多人的視野當中。

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

1. 什麼是 GitOps？
2. 推模式和拉模式
3. GitOps 的主要優點
4. GitOps 關鍵工具

什麼是 GitOps？

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

GitOps 四項原則

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

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

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

經過將系統的目標狀態存儲在具備版本控制功能的系統中，並做爲惟一的事實來源，咱們可以從中派生和驅動一切。

1. 經過 pull request 發起對目標狀態的變動申請，狀態變化清晰呈現，變動 review 簡單明瞭。
2. 系統的每一次變動都對應着一條 git commit，變動行爲可審計。
3. 回滾操做只須要使用git revert命令把目標狀態恢復到前一個狀態。

對目標狀態的變動批准後將自動應用到系統

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

驅動收斂 & 上報偏離

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

GitOps 的簡潔定義

進一步，能夠將 GitOps 總結成如下兩點：

1. 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.
2. 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等方式將新版本直接應用到系統，整個流程以下圖所示。

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

1. 跨越安全邊界共享祕鑰 - 在推模式下，爲了讓 CI 系統可以自動地部署應用，須要將集羣的訪問祕鑰共享給它。雖然能夠經過一些措施進行防禦，但畢竟仍是將祕鑰暴露在了可信度較低的安全上下文中。這種作法擴大了攻擊面，會給系統帶來潛在的安全風險。
2. 回滾操做複雜 - 若是經過 CI 任務完成一次部署後，系統出現異常，你將如何知道應該回滾到哪個版本？你可能須要仔細查看構建日誌才能找到答案。
3. 難以快速重建集羣 - 在集羣徹底崩潰的狀況下進行重建，如何肯定須要部署的每一個應用的版本？你可能須要從新跑一遍 CI 任務。

GitOps 流水線

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

1. 經過 pull request 向主分支提交包含新功能的代碼。
2. 代碼審覈經過後將被合併至主分支。
3. 合併行爲將觸發 CI 系統進行構建和一系列的測試，並將新生成的鏡像推送至鏡像倉庫。
4. GitOps 檢測到有新的鏡像，會提取最新的鏡像標記，而後同步到 Git 配置倉庫的清單中。
5. GitOps 檢測到集羣狀態過時，會從配置倉庫中拉取更新後的清單，並將包含新功能的鏡像部署到集羣裏。

經過爲不一樣的集羣建立各自的子目錄或分支，能夠輕鬆地將該模式拓展到多集羣環境。

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

1. 部署在集羣內部的 GitOps 模塊負責更新集羣，這樣就避免了集羣 API 和祕鑰的跨邊界暴露。更重要的是，流水線中每一個邏輯單元的寫操做都被限定在了安全邊界之內，職責劃分清晰。
2. 因爲每一次變動都對應着一條 git commit，回滾操做只須要簡單的把目標狀態恢復到前一個狀態。
3. 因爲在 Git 的配置倉庫中保留了集羣的目標狀態，若是集羣徹底崩潰，能夠基於倉庫中的清單快速重建集羣。

GitOps 的主要優點

通過上面兩章的介紹，能夠將 GitOps 的優點總結以下：

1. 提升生產力 - 採用集成了反饋控制循環的持續部署流水線能夠大大提高新功能的發佈速度。
2. 提高開發者體驗 - 開發者可使用熟悉的工具 Git 去發佈新功能，而無需瞭解複雜的部署交付流程。新入職的員工能夠在幾天內快速上手，從而提升工做效率。
3. 行爲可審計 - 使用 Git 工做流管理集羣，自然可以得到全部變動的審計日誌，知足合規性需求，提高系統的安全與穩定性。
4. 更高的可靠性 - 藉助 Git 的還原（revert）、分叉（fork）功能，能夠實現穩定且可重現的回滾。因爲整個系統的描述都存放在 Git 中，咱們有了惟一的真實來源，這能大大縮短集羣徹底崩潰後的恢復時間。
5. 一致性和標準化 - 因爲 GitOps 爲基礎設置、應用程序、Kubernetes 插件的部署變動提供了統一的模型，所以咱們能夠在整個組織中實現一致的端到端工做流。不只僅是 CI/CD 流水線由 pull request 驅動，運維任務也能夠經過 Git 徹底重現。
6. 更強的安全保證 - 得益於 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 做爲事實的來源和連接的橋樑，旨在簡化雲原生時代基礎設施和應用程序的部署與管理方式，實現產品更快、更頻繁、更穩定的交付。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。