GitOps：一款基於Kubernetes的高速CI/CD框架

「把世界設想成一套代碼庫，而非Kubernetes環境。」

——Kelsey Hightower

這篇文章主要面向希望使用Kubernetes和Docker進行高速持續交付的用戶而言。 當我們提到「高速」時，我們的意思是每個產品團隊可以安全地每天多次交付更新 ——包括即時部署，實時觀察結果，並通過反饋進行推進或者回滾。其目標，是讓產品團隊儘可能快地通過持續實驗來改善客戶體驗。

如果您還不熟悉GitOps，這是一套可以對現代應用程序進行敏捷化軟體生命周期管理的框架。 感興趣的朋友可以通過閱讀我們的系列博文了解更多，今天讓我們從《Gitops——Pull Request的操作[1]》開始。

用戶案例：高速CI/CD改變遊戲規則

一個團隊如何從每周一次手動部署提升到每天超過三十次的無需額外工作的部署？

Qordoba是一支來自舊金山的團隊，他們利用機器學習技術為各大國際品牌交付經過優化的本地服務。 他們的一個團隊正在使用基於Kubernetes的微服務作為Qordoba後端的一部分。 通過採用我們推薦的GitOps實踐與工具，他們從根本上提高了自身塑造用戶體驗的能力：

修復生產環境軟體錯誤所需的預計時間：使用Weave Cloud後，所需時間縮短60％

響應客戶請求的預計時間：使用Weave Cloud後，時間縮短約43％

正常運行時間從99％提升到100％（到目前為止……）

Qordoba從每周部署1或2次提升到了每天部署超過30次。更重要的是，每一項部署實質上都是「零成本」的。 這意味著：其需要的時間很短，不致中途中斷並導致團隊無法將系統恢復至良好狀態，且所有變更皆可實現回滾。 零成本部署解放了開發團隊，讓他們專註於用戶體驗和業務邏輯——即真正能夠創造價值的工作，並按照自己適應的速度進行迭代，且無需擔心失敗成本。

了解更多：GitOps介紹資料

我在KubeCon 2017上和Google的項目經理William Denniss共同演示了這個用例。

一些背景：Weaveworks已經在AWS上擁有長達兩年的生產環境的Kubernetes雲服務運行周期。最近我們總結了一些最佳實踐，我們稱之為「GitOps」[2]。 GitOps基於經過驗證的DevOps技術——大體類似於CI/CD和聲明式基礎設施即代碼——而構建，為Kubernetes應用程序提供了一套聯合的、可自動生成的生命周期框架。 我們在KubeCon上和Google Cloud Platform一起推出了「免費」的GitOps功能[3]。

如果您有興趣了解我們是如何做到這一點的，例如創建一條高速CI/CD流水線，那麼我建議您查看這個演示文稿（視頻[4]和幻燈片[5]）。

KubeCon是一項社區活動，所以在本演講中，William和我談論了解決方案的模式、Kubernetes部署運維工程師的技術角色以及其它與之配合的開源項目。

即時Kubernetes CI/CD與Weave Cloud

如果你喜歡這個演示文稿以及GitOps的創意，那麼你可能會打算新手上手一試。 最便捷的方式當然是通過由Google上提供的Weave Cloud設置。

這些會讓你獲得：

一條可以在幾分鐘內搭建的Kubernetes流水線

一鍵部署的應用（當然，如果有必要仍然需要手動分段）

全面的可觀察性、儀錶板與警報

Weave Cloud可以輕鬆將您的Git存儲庫接入至任何CI。 其為CI/CD建立一套Kubernetes集群，以便您可以從之前提到的Qordoba持續與高速交付中受益。 在Google雲上，您的GKE群集可以輕鬆連接到Google的容器構建器和存儲庫。 但我們希望再次強調：Weave Cloud可以與任何集群、任何網路、任何CI以及任何Git庫協同工作——我們不會強迫你選擇自己不喜歡的道路。

有鑒於此，您可以通過Git PR、CLI或GUI對應用程序進行更新和回滾。 最後，我們提供集成化「全棧式」監控和管理，以完成運整個操作循環。 Weave提供的集成方案意味著開發人員可以觀察部署情況，從而衡量並應對各類變化及其產生的影響。 下圖所示為一套示例UI。

開源GitOps

我們的雲服務為利用Kubernetes實現GitOps提供了一種方便且令人滿意的方式。 但是如果你是一位希望建立並了解自己開源流水線的開發者呢？ 請閱讀下面的內容來了解可供選擇的一些GitOps方法。

方法1——使用Weave Flux部署Operator

我們建議您使用Operator模式來監聽和編排部署到您Kubernetes集群中的服務。William Denniss在我們KubeCon演示資料的第15-21頁中描述了這種方法。使用Operator，代理可以代表集群來監聽與自定義資源變更相關的事件，並通過一致性方式加以應用。換句話說，Operator負責執行Git和集群之間的協調工作。

Operator是由Weave Flux這個開源項目實現的。這個項目的誕生，源自我們為了簡化Weave Cloud將微服務部署到Kubernetes而作出的大量痛苦嘗試。請參閱這篇博客文章《GitOps管道》[6]，文中闡述了編排部署相較於通過CI+腳本（「CI操作」）手工編寫代碼的種種優勢。

Flux被應用於我們的Weave Cloud服務。我們建議你在雲端加以嘗試或自行探索設置方法。我們同樣歡迎外部的開源代碼貢獻者和對Flux感興趣的公司參與項目當中。多種CI和部署工具都能夠通過部署Operator受益——請與我們聯繫。

方法2——GitOps，Kelsey方法的實現基礎

Kelsey Hightower有一個非常好的習慣，即提供簡單但始終以開發人員為關注重點的精彩演示。他在KubeCon的主題演講自然也不例外。

Kelsey的演講主要探討如何使用Github和Google Cloud進行持續交付，而其出發點為「kubectl就是新的SSH……如果您正在使用kubectl從筆記本電腦部署軟體到生產環境，那麼您已經錯失了幾項重要步驟……」。接下來他提供了一個demo，展示了如何通過CI與分段實現從Git到生產環境的直觀儀錶板實現步驟。這些步驟簡潔直觀且乾貨滿滿，我建議觀看他演講的視頻[7]。

Kelsey的分析建立在兩個前提上：

Kubernetes的部署未能完全解決問題。他說：「有多少人擁有端到端的連續交付流水線？」一旦決定使用kubernetes，這將成為一個可望而不可及的目標……並導致你投入大量時間。」

開發人員希望通過Git來驅動變更，並觀察結果。他說：「在理想情況下，如果我變更了代碼，肯定希望單純通過一條URL來告訴我它在哪裡運行……如果你能給我度量指標，告訴我它運行得如何，那肯定更好。最好的結果是，你能夠給予可見性，用戶就不會再懷疑像kubectl這樣的工具是否真像你宣傳的那麼好——因為現在他們已經能夠實際觀察到集群中發生了什麼。」

這與我們在GitOps上希望達到的目標大致相同。其中的關鍵在於，將Git視為您技術堆棧中所有狀態的理想來源——包括集群、配置，應用程序和工具——並配合使用聲明式基礎設施即代碼。請閱讀我們的第一篇博客文章《Pull Request的操作[8]》了解更多詳情。

選擇你的GitOps探索之旅

在這篇文章中，我們提供了三種嘗試高速CI/CD的方法。

一項開箱即用的服務，使用Weave Cloud提供的從Git到GKE集群的默認CI/CD流水線，包括監控、可觀察性、審計和功能，且支持彈性伸縮。這項服務也適用於其他Kubernetes供應方案及您自己的CI。

引入Weave Flux，我們在第1條中也需要使用到這款獨立且開源的部署執行程序。其能夠運行您所使用的任何Kubernetes集群。

Kelsey演示了如何設置自己的簡單GitHub-to-Google流水線。

這三種方法在實際效果上完全一致。下面我們來具體作出比較。

Weave Cloud服務最易於上手，因為它為您設置了GitOps流水線，並且包含對GitOps可觀察性的大量支持，這本身就是一個重要的問題。借用Kelsey的原話——我們希望「讓人們看到……實現目標的最好辦法就是為人們提供一套儀錶板，藉此展示實際發生的狀況」。

Weave Flux開源Operator只聚焦於CI/CD中的「CD」部分。通過使用Flux，用戶將可以對發布工作流程進行大規模重複與管理——且實現難度要比使用「kubectl」或將腳本捆綁到CI工具上容易得多。 Flux是一種協調與通知代理，能夠「與本地Kubernetes交互」，以便對任何Kubernetes對象進行集群變更，包括實現對同步代碼、配置文件、容器、標籤等的更改。您還可以獲得諸如「回滾」，「自動」，「手動」部署等策略（還有更多，例如藍/綠和金絲雀部署等）。

Kelsey的方法當然也可以進一步分解成更小的部分。他提供了從Git到CI到GKE的集成示例，但並沒有提到像Flux Operator這樣的程序化代理。將Kelsey的方法與Flux結合起來顯然是種合乎邏輯的作法。事實上，我們的KubeCon演示文稿在第21頁就展示了這種集成方法：

還要注意的是，Kelsey建議在他的演示中使用一套精心設計的儀錶板——Grafana。 我們對此深表贊同，並在我們的雲服務中也提供這樣的工具——同時還集成有Slack。

隱私問題如何解決？

這是迄今為止關於GitOps最常問到的問題。

好消息是，我們在Bitnami的朋友創建了一個專門用於GitOps工作流程的Sealed Secrets開源項目[9]。 Sealed Secrets是一款定製化Kubernetes資源定義控制器，它甚至允許您在Git中存儲敏感信息（即secrets）——這在以前是完全無法想像的。 另請參閱《構建Serverless應用程序流水線[10]》，由同樣參加了KubeCon大會、來自Bitnami公司的Sebastien Goasguen提供。

另外，您可以將Weave Cloud的部署功能與Sealed Secrets結合使用，從而創建一套連續的部署流水線——其中所有操作皆基於Git實現，且您應用程序的全部所需狀態都會在Git倉庫中聲明，包括您的隱私。

Helm效果如何？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！