GitOps中推送與拉取兩種風格的區別 – thenewstack

自從出現第一個“基礎結構即程式碼”工具以來，人們就意識到對版本進行環境定義的版本控制和自動執行更改是很有意義的。您可以說那些早期的先驅者正在使用Git進行操作。或者，您可以將其稱為GitOps。

就像敏捷，DevOps或雲原生一樣，經常有人可能會問：“我們真的需要另一個營銷流行語嗎？作為既是工程師又是營銷人員的人，我認為GitOps一詞的產生更多是出於工程需求，而不是營銷需求。

軟體工程的基本原則是抽象實踐。我們將可重複的步驟抽象到函式中，將函式抽象到庫中，將庫抽象到框架中，然後將這些框架一起構建到工具中，然後不斷進行抽象，直到獲得Kubernetes。這與在我們的語言中使用抽象的概念非常相似。

您可以使用一個單詞“ GitOps”作為一個簡單概括，讓人們可以知曉其中更豐富和更深層的含義。

但是，當您知道如何呼叫API卻不瞭解底層執行時可能會出現麻煩，因此呼叫GitOps也會返回意外結果。

對於GitOps的兩種主要風格：“ 推送push”和“ 拉取pull”確實是這種情況。那麼，推和拉GitOps之間真的有什麼區別嗎？

Push

在這種樣式中，您使用CI / CD（連續整合/連續交付）管道將更改推送到您的環境，管道由程式碼提交或合併觸發。

好處：

• 簡便性：由於push使用了易於理解的CI / CD工具，因此對於組織中最廣泛的工程師來說，它將是最容易使用的工具。這通常意味著您可以更快地開始，並擁有更廣泛的協作池。
• 靈活性：如今，大多數拉式GitOps代理僅在Kubernetes中執行。如果要部署到Kubernetes以外的任何其他裝置，則需要將配置推送到該環境。可以使用在Kubernetes群集中執行的pull GitOps代理來協調對外部目標（如VM和裸機）的部署，但最終您將回到推送狀態。該代理正在推動那些環境。您最終需要管理許多相同的安全問題，即在環境外部儲存憑據以及開啟網路防火牆埠以允許入站連線。
• 效率：針對您的雲原生和傳統工作負載，採用相同的部署方法進行標準化可以提高您的效率。通過減少認知開銷，您可以更輕鬆地入職和培訓新團隊成員，同時確保現有團隊成員專注於解決問題，而不是瞭解多種技術。
• 優化的頻寬：使用Kubernetes代理不斷輪詢您的Git儲存庫以查詢更改可能不是幾個群集的問題，但是從規模上講，您可以體驗到有意義的網路資源消耗。此外，如果您的Git和容器登錄檔工具需要處理來自數百個群集的請求，並且不斷輪詢狀態，則它可能會承受巨大的負擔。您可以縮短輪詢間隔，但同時也會增加程式碼提交和部署之間的延遲。藉助推式GitOps，您可以在快速，低延遲的部署中獲得兩全其美的優勢，同時將網路和工具的負擔降至最低。

Pull

使用pull GitOps，在您的環境中執行的代理會不斷輪詢您的Git儲存庫和/或容器登錄檔中是否有更改。當它檢測到已定義狀態和執行狀態之間不匹配時，代理會將已定義的配置拉入環境。

好處：

• 原生雲：如果您的全部或大部分工作負載都在Kubernetes中執行，那麼使用代理進行部署可以是簡單有效的選擇。與所有其他Kubernetes運營商一樣，使用和管理CD代理也是如此。
• 安全性：使用pull GitOps可以降低安全性和合規性風險。由於CD代理在群集內部執行，因此無需在外部CI中儲存憑據。同樣，您可以減少或消除防火牆中允許入站連線的漏洞。
• 一致性：推送GitOps通常僅在一個方向上工作，從Git儲存庫到環境。拉動GitOps的工作方向也相反。代理不僅可以輪詢Git儲存庫和容器登錄檔中的更改，還可以將群集狀態與Git中定義的狀態進行比較。在手動或從其他來源對叢集進行更改的情況下，這可以檢測和糾正配置偏差。可以將推式CI / CD設定為定期輪詢您的環境，將執行狀態與已定義狀態進行比較，並在配置發生漂移時恢復到已定義狀態，但這是您需要設定的額外內容。大多數Pull GitOps代理都帶有此雙向比較，作為一項功能，您無需使用其他設定即可簡單地使用該代理。

總結

歸根結底，沒有必要過於嚴格，在練習GitOps的過程中，您可以進行一些推拉操作（雙關語）。權衡每種方法的利弊對團隊或組織的需求，將幫助您決定使用其中一個或兩個。儘管每種樣式都不同，但是兩者都會為您帶來好處，例如通過合併請求/拉取請求管理操作所帶來的增強的協作和合規性，以及自動化基礎架構和部署所帶來的增強的穩定性和彈性。