筆記。 翻譯。: 最近發表後 關於 GitOps 中的拉和推方法，我們普遍看到了對這個模型的興趣，但是關於這個主題的俄語出版物很少（關於 Habré 根本沒有）。 因此，我們很高興向您提供另一篇文章的翻譯，儘管是一年前的事了！ ——來自 Weaveworks，該公司的負責人創造了術語「GitOps」。 文本解釋了該方法的本質以及與現有方法的主要差異。
一年前我們發表了 。 當時，我們分享了 Weaveworks 團隊如何推出完全基於 Kubernetes 的 SaaS，並開發了一套用於在雲端原生環境中部署、管理和監控的規範性最佳實踐。
這篇文章很受歡迎。 其他人開始談論 GitOps 並開始發布新工具 , , , , 等等。 出現在我們的網站上 出版物和 GitOps 用例。 但有些人仍有疑問。 該模型與傳統模型有何不同？ 和持續交付（）？ 有必要使用Kubernetes嗎？
我們很快意識到需要一個新的描述，提供：
- 大量的例子和故事；
- GitOps的具體定義；
- 與傳統持續交付的比較。
在本文中，我們試圖涵蓋所有這些主題。 它提供了 GitOps 的最新介紹以及開發人員和 CI/CD 視角。 儘管該模型可以推廣，但我們主要關注 Kubernetes。
認識 GitOps
想像一下愛麗絲。 她經營家庭保險，為那些太忙而無法自己弄清楚合約細節的人提供健康、汽車、家庭和旅遊保險。 當愛麗絲在一家銀行擔任資料科學家時，她的生意開始於一個業餘專案。 有一天，她意識到她可以使用先進的電腦演算法來更有效地分析數據並製定保險方案。 投資者為該項目提供了資金，現在她的公司每年收入超過 20 萬美元，並且發展迅速。 目前，該公司擁有不同職位的員工180人。 這包括開發、維護網站、資料庫和分析客戶群的技術團隊。 這個 60 人的團隊由公司技術總監 Bob 領導。
Bob 的團隊在雲端部署生產系統。 他們的核心應用程式在 GKE 上運行，利用 Google Cloud 上的 Kubernetes。 此外，他們在工作中使用各種數據和分析工具。
Family Insurance 並沒有打算使用容器，而是被 Docker 的熱情所吸引。 該公司很快就發現 GKE 可以輕鬆部署叢集來測試新功能。 新增了 Jenkins for CI 和 Quay 來組織容器註冊表，為 Jenkins 編寫了腳本，將新容器和配置推送到 GKE。
一段時間過去了。 Alice 和 Bob 對他們選擇的方法的表現及其對業務的影響感到失望。 容器的引入並沒有像團隊希望的那樣提高生產力。 有時部署會中斷，且不清楚程式碼變更是否是罪魁禍首。 事實證明，追蹤配置更改也很困難。 通常有必要建立一個新的叢集並將應用程式移至其中，因為這是消除系統混亂的最簡單方法。 Alice 擔心隨著應用程式的開發情況會變得更糟（此外，一個基於機器學習的新專案正在醞釀中）。 Bob 已經自動化了大部分工作，但不明白為什麼管道仍然不穩定，無法很好地擴展，並且需要定期手動幹預？
然後他們了解了 GitOps。 事實證明，這個決定正是他們自信地前進所需要的。
Alice 和 Bob 多年來一直聽說 Git、DevOps 和基礎架構即程式碼工作流程。 GitOps 的獨特之處在於，它帶來了一組最佳實踐（既明確又規範），用於在 Kubernetes 環境中實現這些想法。 這個主題 ，包括在 .
Family Insurance 決定實作 GitOps。 本公司現已擁有相容 Kubernetes 並結合自動化營運模式 速度 同 穩定因為他們：
- 發現團隊的生產力翻了一番，而沒有人發瘋；
- 停止提供腳本。 相反，他們現在可以專注於新功能並改進工程方法 - 例如，引入金色雀部署和改進測試；
- 我們改進了部署流程，使其很少出現故障；
- 有機會在部分故障後恢復部署，無需人工幹預；
- 購買二手的о對交付系統更有信心。 Alice 和 Bob 發現他們可以將團隊分成並行工作的微服務團隊；
- 透過每個小組的努力，每天可以對專案進行30-50次修改並嘗試新技術；
- 很容易吸引新的開發人員加入該項目，他們有機會在幾個小時內使用拉取請求將更新推出到生產環境；
- 輕鬆通過SOC2框架內的審核 （使服務提供者遵守安全資料管理的要求；了解更多信息，例如， - 大約。 譯）.
發生了什麼？
GitOps 有兩件事：
- Kubernetes 和雲端原生的營運模式。 它提供了一組用於部署、管理和監控容器化叢集和應用程式的最佳實踐。 優雅的形式定義 從 :
- 創建以開發人員為中心的應用程式管理環境的途徑。 我們將Git工作流程應用到營運和開發中。 請注意，這不僅僅是關於 Git 推送，而是關於組織整套 CI/CD 和 UI/UX 工具。
關於 Git 的幾句話
如果您不熟悉版本控制系統和基於 Git 的工作流程，我們強烈建議您了解它們。 使用分支和拉取請求乍看之下似乎像是黑魔法，但其好處是值得付出努力的。 這裡 開始。
Kubernetes 的工作原理
在我們的故事中，Alice 和 Bob 在使用 Kubernetes 一段時間後轉向了 GitOps。 事實上，GitOps 與 Kubernetes 密切相關——它是基於 Kubernetes 的基礎設施和應用程式的營運模式。
Kubernetes 為用戶帶來了什麼？
以下是一些主要特點：
- 在 Kubernetes 模型中，一切都可以用宣告式的形式來描述。
- Kubernetes API 伺服器將此聲明作為輸入，然後不斷嘗試使叢集進入聲明中所述的狀態。
- 聲明足以描述和管理各種工作負載—「應用程式」。
- 因此，應用程式和叢集會因以下原因發生變更：
- 容器鏡像的變化；
- 聲明性規範的更改；
- 環境中的錯誤 - 例如容器崩潰。
Kubernetes 強大的融合能力
當管理員進行設定變更時，Kubernetes Orchestrator 會將它們套用到集群，只要其狀態為 不會接近新配置。 此模型適用於任何 Kubernetes 資源，並且可透過自訂資源定義 (CRD) 進行擴充。 因此，Kubernetes 部署具有以下奇妙的特性：
- 自動化：Kubernetes 更新提供了一種機制，可以自動、優雅地、及時地應用更改的過程。
- 收斂：Kubernetes 將繼續嘗試更新，直到成功。
- 冪等性：重複應用收斂會導致相同的結果。
- 決定論：當資源充足時，更新後的叢集狀態僅取決於期望的狀態。
GitOps 的工作原理
我們已經了解了足夠的 Kubernetes 知識來解釋 GitOps 的工作原理。
讓我們回到 Family Insurance 的微服務團隊。 他們通常需要做什麼？ 請看下面的清單（如果其中有任何項目看起來很奇怪或不熟悉，請不要批評並繼續關注我們）。 這些只是基於 Jenkins 的工作流程的範例。 使用其他工具時還有許多其他流程。
最主要的是我們看到每次更新都會對設定檔和 Git 儲存庫進行更改。 對 Git 的這些變更會導致「GitOps 操作員」更新叢集：
1.工作流程：》Jenkins 建置 - 主分支“。
任務清單：
- Jenkins 將標記的映像推送到 Quay；
- Jenkins將配置和Helm圖表推送到主儲存桶；
- 雲端功能將主儲存桶中的配置和圖表複製到主Git儲存庫中；
- GitOps 操作員更新叢集。
2. Jenkins 建置 - 發布或修補程式分支:
- Jenkins 將未標記的映像推送到 Quay；
- Jenkins 將配置和 Helm 圖表推送到暫存儲存桶；
- 雲端功能將設定和圖表從暫存儲存桶複製到暫存 Git 儲存庫；
- GitOps 操作員更新叢集。
3. Jenkins 建置 - 開發或功能分支:
- Jenkins 將未標記的映像推送到 Quay；
- Jenkins 將配置和 Helm 圖表推送到開發儲存桶中；
- 雲端功能將開發儲存桶中的配置和圖表複製到開發Git儲存庫中；
- GitOps 操作員更新叢集。
4. 新增客戶:
- 經理或管理員 (LCM/ops) 呼叫 Gradle 來初始部署和配置網路負載平衡器 (NLB)；
- LCM/ops 提交新配置以準備更新部署；
- GitOps 操作員更新叢集。
GitOps 簡述
- 使用每個環境的聲明性規格來描述整個系統的所需狀態（在我們的故事中，Bob 的團隊在 Git 中定義了整個系統配置）。
- Git 儲存庫是整個系統所需狀態的唯一事實來源。
- 對所需狀態的所有變更都是透過 Git 中的提交進行的。
- 所有所需的集群參數也可以在集群本身中觀察到。 這樣我們就可以判斷它們是否重合（收斂， 收斂）或不同（發散， 偏離）期望的和觀察到的狀態。
- 如果期望的狀態和觀察到的狀態不同，則：
- 有一種收斂機制遲早會自動同步目標狀態和觀察到的狀態。 在叢集內部，Kubernetes 執行此操作。
- 該過程立即開始，並發出“更改已提交”警報。
- 經過一段可配置的時間後，如果狀態不同，則可以發送「差異」警報。
- 這樣，Git 中的所有提交都會導致對叢集進行可驗證且冪等的更新。
- 回滾是收斂到先前期望的狀態。
- 收斂是最終的。 其發生由以下情況表示：
- 在一段時間內沒有差異警報。
- 「聚合」警報（例如 webhook、Git 寫回事件）。
什麼是背離？
讓我們再重複一遍： 所有所需的集群屬性必須在集群本身中是可觀察的.
一些背離的例子：
- 由於合併 Git 中的分支而導致設定檔發生變更。
- 由於 GUI 用戶端進行的 Git 提交而導致設定檔發生變更。
- 由於 Git 中的 PR，隨後建立容器映像並更改配置，對所需狀態進行了多次更改。
- 由於錯誤、導致「不良行為」的資源衝突或簡單地隨機偏離原始狀態而導致群集狀態發生變化。
收斂機制是什麼？
舉幾個例子：
- 對於容器和叢集來說，收斂機制是由Kubernetes提供的。
- 相同的機制可用於管理基於 Kubernetes 的應用程式和設計（例如 Istio 和 Kubeflow）。
- 提供了管理 Kubernetes、鏡像儲存庫和 Git 之間操作互動的機制 ，這是一部分 .
- 對於基礎機器，收斂機制必須是聲明性的和自治的。 根據我們自己的經驗，我們可以說 最接近這個定義，但仍然需要人類控制。 從這個意義上說，GitOps 擴展了基礎架構即程式碼的傳統。
GitOps 將 Git 與 Kubernetes 優秀的融合引擎結合起來，提供了一種利用模型。
GitOps 允許我們說： 只有那些可以描述和觀察的系統才能實現自動化和控制.
GitOps 適用於整個雲端原生堆疊（例如 Terraform 等）
GitOps 不只是 Kubernetes。 我們希望整個系統以聲明方式驅動並使用收斂性。 整個系統是指使用 Kubernetes 的環境集合，例如「開發叢集 1」、「生產環境」等。每個環境包括機器、叢集、應用程式以及提供資料、監控的外部服務的介面等等。
請注意，在這種情況下，Terraform 對於引導問題有多重要。 Kubernetes 必須部署在某個地方，使用 Terraform 意味著我們可以應用相同的 GitOps 工作流程來建立支援 Kubernetes 和應用程式的控制層。 這是一個有用的最佳實踐。
人們非常關注將 GitOps 概念應用到 Kubernetes 之上的層。 目前，有針對 Istio、Helm、Ksonnet、OpenFaaS 和 Kubeflow 的 GitOps 類型解決方案，以及 Pulumi 等，它們創建了一個用於開發雲端原生應用程式的層。
Kubernetes CI/CD：GitOps 與其他方法的比較
如前所述，GitOps 包含兩件事：
- 上面描述的 Kubernetes 和雲端原生的操作模型。
- 通往以開發人員為中心的應用程式管理環境的道路。
對許多人來說，GitOps 主要是基於 Git 推送的工作流程。 我們也喜歡他。 但這還不是全部：現在讓我們看看 CI/CD 管道。
GitOps 為 Kubernetes 提供持續部署 (CD)
GitOps 提供了一種持續部署機制，無需單獨的「部署管理系統」。 Kubernetes 會為您完成所有工作。
- 更新應用程式需要在 Git 中更新。 這是所需狀態的事務更新。 然後，Kubernetes 本身根據更新的描述在叢集內完成「部署」。
- 由於 Kubernetes 工作方式的本質，這些更新是收斂的。 這提供了一種持續部署的機制，其中所有更新都是原子的。
- 注： 提供整合了 Git 和 Kubernetes 的 GitOps Operator，並允許透過協調叢集的所需狀態和當前狀態來執行 CD。
沒有 kubectl 和腳本
您應該避免使用 Kubectl 更新集群，尤其是避免使用腳本對 kubectl 命令進行分組。 相反，借助 GitOps 管道，使用者可以透過 Git 更新其 Kubernetes 叢集。
示例：
- 正確的。 一組更新可以被應用、聚合並最終驗證，使我們更接近原子部署的目標。 相反，使用腳本並不能提供任何收斂保證（更多內容見下文）。
- 安全. Kelsey Hightower：“將 Kubernetes 叢集的存取權限限制為自動化工具和負責調試或維護叢集的管理員。” 也可以看看 關於安全和遵守技術規範，以及 透過從粗心編寫的 Jenkins 腳本中竊取憑證。
- 用戶體驗。 Kubectl 公開了相當複雜的 Kubernetes 物件模型的機制。 理想情況下，使用者應該在更高的抽象層級與系統互動。 在這裡我再次提到凱爾西並推薦觀看 .
CI 和 CD 的區別
GitOps 改進了現有的 CI/CD 模型。
現代 CI 伺服器是一種編排工具。 特別是，它是一個用於編排 CI 管道的工具。 其中包括建置、測試、合併到主幹等。CI 伺服器自動管理複雜的多步驟管道。 一種常見的誘惑是編寫一組 Kubernetes 更新腳本，並將其作為管道的一部分運行，以將變更推送到叢集。 事實上，許多專家都是這樣做的。 然而，這並不是最佳的，原因如下。
應該使用 CI 將更新推送到主幹，並且 Kubernetes 叢集應該根據這些更新進行自身變更以在內部管理 CD。 我們稱之為 ，與 CI 推送模型不同。 CD是一部分 運行時編排.
為什麼 CI 伺服器不應該透過 Kubernetes 中的直接更新進行 CD
不要使用 CI 伺服器將 Kubernetes 的直接更新編排為一組 CI 作業。 這就是我們正在討論的反模式 在你的博客上。
讓我們回到愛麗絲和鮑伯。
他們遇到了什麼問題？ Bob 的 CI 伺服器將變更應用到集群，但如果在此過程中崩潰，Bob 將不知道集群處於（或應該）處於什麼狀態，也不知道如何修復它。 成功的情況也是如此。
我們假設 Bob 的團隊建立了一個新映像，然後修補了他們的部署以部署該映像（全部來自 CI 管道）。
如果圖像構建正常，但管道失敗，團隊將必須弄清楚：
- 更新已經推出了嗎？
- 我們要推出新版本嗎？ 這是否會導致不必要的副作用——可能會產生同一個不可變圖像的兩個版本？
- 我們應該在運行建置之前等待下一次更新嗎？
- 究竟出了什麼問題？ 哪些步驟需要重複（哪些步驟可以安全重複）？
建立基於 Git 的工作流程並不能保證 Bob 的團隊不會遇到這些問題。 他們仍然可能在提交推送、標籤或其他一些參數方面犯錯； 然而，這種方法仍然更接近明確的「全有或全無」方法。
總而言之，這就是 CI 伺服器不應該處理 CD 的原因：
- 更新腳本並不總是確定性的； 他們很容易犯錯。
- CI 伺服器不收斂於宣告式叢集模型。
- 很難保證冪等性。 使用者必須理解系統的深層語意。
- 從部分故障中恢復更加困難。
關於 Helm 的注意事項：如果您想使用 Helm，我們建議將其與 GitOps 運算子結合使用，例如 。 這將有助於確保收斂。 Helm 本身既不是確定性的也不是原子性的。
GitOps 是實現 Kubernetes 持續交付的最佳方式
Alice 和 Bob 的團隊實施了 GitOps，發現使用軟體產品、維持高效能和穩定變得更加容易。 讓我們用一張插圖來結束本文，展示他們的新方法是什麼樣子的。 請記住，我們主要討論的是應用程式和服務，但 GitOps 可用於管理整個平台。
Kubernetes 的營運模型
看下圖。 它將 Git 和容器鏡像儲存庫呈現為兩個精心安排的生命週期的共享資源：
- 一個持續整合管道，用於讀取檔案並將其寫入 Git，並可以更新容器映像儲存庫。
- 將部署與管理和可觀察性結合的執行時間 GitOps 管道。 它可以讀取檔案並將其寫入 Git，並且可以下載容器映像。
主要發現是什麼？
- 關注點分離：請注意，兩個管道只能透過更新 Git 或鏡像儲存庫進行通訊。 換句話說，CI和運行時環境之間有一道防火牆。 我們稱之為“不變性防火牆” （不變性防火牆），因為所有儲存庫更新都會建立新版本。 有關此主題的更多信息，請參閱幻燈片 72-87 .
- 您可以使用任何 CI 和 Git 伺服器：GitOps 可與任何組件配合使用。 您可以繼續使用您最喜歡的 CI 和 Git 伺服器、圖像儲存庫和測試套件。 市場上幾乎所有其他持續交付工具都需要自己的 CI/Git 伺服器或影像儲存庫。 這或許會成為雲端原生發展的限制因素。 透過 GitOps，您可以使用熟悉的工具。
- 事件作為整合工具：一旦 Git 中的資料更新，Weave Flux（或 Weave Cloud 運算子）就會通知執行時。 每當 Kubernetes 接受更改集時，Git 就會更新。 這提供了一個簡單的整合模型來組織 GitOps 的工作流程，如下所示。
結論
GitOps 提供任何現代 CI/CD 工具所需的強大更新保證：
- 自動化;
- 收斂;
- 冪等性；
- 決定論。
這很重要，因為它為雲端原生開發人員提供了一個操作模型。
- 用於管理和監控系統的傳統工具與在運作手冊中操作的營運團隊相關聯 （一組例行程序和操作 - 大約翻譯），與特定部署相關。
- 在雲端原生管理中，可觀察性工具是衡量部署結果的最佳方式，以便開發團隊能夠快速回應。
想像一下，許多叢集分散在不同的雲端中，並且許多服務都有自己的團隊和部署計劃。 GitOps 提供了一個規模不變的模型來管理所有這些豐富的內容。
譯者PS
另請閱讀我們的博客：
- «“;
- «“;
- «“。
只有註冊用戶才能參與調查。 ， 請。
在這兩個翻譯出現在 Habré 之前，您了解 GitOps 嗎？
-
是的，我知道一切
-
只是表面上
-
沒有
35 位用戶投票。 10 名用戶棄權。
來源： www.habr.com