“把世界設想成一套程式碼庫，而非Kubernetes環境。”
這篇文章主要面向希望使用Kubernetes和Docker進行高速持續交付的使用者而言。 當我們提到“高速”時，我們的意思是每個產品團隊可以安全地每天多次交付更新 ——包括即時部署，實時觀察結果，並透過反饋進行推進或者回滾。其標的，是讓產品團隊盡可能快地透過持續實驗來改善客戶體驗。
如果您還不熟悉GitOps，這是一套可以對現代應用程式進行敏捷化軟體生命週期管理的框架。 感興趣的朋友可以透過閱讀我們的系列博文瞭解更多，今天讓我們從《Gitops——Pull Request的操作[1]》開始。
一個團隊如何從每週一次手動部署提升到每天超過三十次的無需額外工作的部署？
Qordoba是一支來自舊金山的團隊，他們利用機器學習技術為各大國際品牌交付經過最佳化的本地服務。 他們的一個團隊正在使用基於Kubernetes的微服務作為Qordoba後端的一部分。 透過採用我們推薦的GitOps實踐與工具，他們從根本上提高了自身塑造使用者體驗的能力：
-
修複生產環境軟體錯誤所需的預計時間：使用Weave Cloud後，所需時間縮短60％
-
響應客戶請求的預計時間：使用Weave Cloud後，時間縮短約43％
-
正常執行時間從99％提升到100％（到目前為止……）
Qordoba從每週部署1或2次提升到了每天部署超過30次。更重要的是，每一項部署實質上都是“零成本”的。 這意味著：其需要的時間很短，不致中途中斷並導致團隊無法將系統恢復至良好狀態，且所有變更皆可實現回滾。 零成本部署解放了開發團隊，讓他們專註於使用者體驗和業務邏輯——即真正能夠創造價值的工作，並按照自己適應的速度進行迭代，且無需擔心失敗成本。
我在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。
我們的雲服務為利用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]。
-
Kubernetes的部署未能完全解決問題。他說：“有多少人擁有端到端的連續交付流水線？”一旦決定使用kubernetes，這將成為一個可望而不可及的標的……並導致你投入大量時間。”
-
開發人員希望透過Git來驅動變更，並觀察結果。他說：“在理想情況下，如果我變更了程式碼，肯定希望單純透過一條URL來告訴我它在哪裡執行……如果你能給我度量指標，告訴我它執行得如何，那肯定更好。最好的結果是，你能夠給予可見性，使用者就不會再懷疑像kubectl這樣的工具是否真像你宣傳的那麼好——因為現在他們已經能夠實際觀察到叢集中發生了什麼。”
這與我們在GitOps上希望達到的標的大致相同。其中的關鍵在於，將Git視為您技術堆疊中所有狀態的理想來源——包括叢集、配置，應用程式和工具——並配合使用宣告式基礎設施即程式碼。請閱讀我們的第一篇部落格文章《Pull Request的操作[8]》瞭解更多詳情。
在這篇文章中，我們提供了三種嘗試高速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。
好訊息是，我們在Bitnami的朋友建立了一個專門用於GitOps工作流程的Sealed Secrets開源專案[9]。 Sealed Secrets是一款定製化Kubernetes資源定義控制器，它甚至允許您在Git中儲存敏感資訊（即secrets）——這在以前是完全無法想象的。 另請參閱《構建Serverless應用程式流水線[10]》，由同樣參加了KubeCon大會、來自Bitnami公司的Sebastien Goasguen提供。
另外，您可以將Weave Cloud的部署功能與Sealed Secrets結合使用，從而建立一套連續的部署流水線——其中所有操作皆基於Git實現，且您應用程式的全部所需狀態都會在Git倉庫中宣告，包括您的隱私。
Helm charts是一種將複雜Kubernetes應用程式打包併進行原子部署的好方法。 要瞭解更多關於Helm的資訊，我推薦Vic Iglesias帶來的這段很酷的KubeCon談話[11]。
我們正在努力將Helm charts作為GitOps工作流程中的首要物件。這是一個非常令人興奮的想法：它結合了Helm的好處，即“chart”封裝與模板；外加GitOps本身的好處，其中包括：各版本部署歷史記錄，用於幫助重新建立叢集; 實現叢集狀態更新自動化以反映charts及其自定義更新；以及透過叢集狀態更新自動化以反映容器映象的開啟等等：）
-
https://www.weave.works/blog/gitops-operations-by-pull-request
-
https://www.weave.works/blog/gitops-operations-by-pull-request
-
https://www.weave.works/press/releases/weave-cloud-on-the-google-cloud-platform/
-
https://www.youtube.com/watch?v=BSqE2RqctNs&list;=PLj6h78yzYM2P-3
-
https://www.slideshare.net/weaveworks/gitops-modern-best-practices-for-high-velocity-app-dev-using-cloud-native-tools
-
https://www.weave.works/blog/the-gitops-pipeline
-
https://www.youtube.com/watch?v=07jq-5VbBVQhttps://www.youtube.com/watch?v=07jq-5VbBVQ
-
https://www.weave.works/blog/gitops-operations-by-pull-request
-
https://github.com/bitnami/sealed-secrets
-
https://www.youtube.com/watch?v=8P-aXKylCVs
-
https://www.youtube.com/watch?v=WugC_mbbiWU
原文連結：https://www.weave.works/blog/gitops-high-velocity-cicd-for-kubernetes
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球