GitOps 簡化并自動化了SDLC中最繁重的手動操作——基礎(chǔ)設(shè)施配置和管理。GitOps 使DevOps 基礎(chǔ)架構(gòu)更具彈性、一致和可靠，如果您依賴手動部署，這些特性需要大量財富才能實現(xiàn)。

本文解釋了 GitOps 是什么，并列出了該策略為軟件開發(fā)團隊和項目帶來的好處。繼續(xù)閱讀以清楚地了解采用 GitOps 是否對您的公司來說是一項值得的投資。

什么是 GitOps？

GitOps 是將應用程序開發(fā)的DevOps 原則應用于基礎(chǔ)設(shè)施管理的實踐。借助 GitOps，開發(fā)人員將基礎(chǔ)架構(gòu)視為代碼，就像對待應用程序代碼一樣，以自動更新并使更改可追溯。

采用 GitOps 的團隊將基礎(chǔ)架構(gòu)配置文件編寫為代碼，并將它們保存在專用的Git存儲庫中。Git 充當所有基礎(chǔ)架構(gòu)的單一事實來源，它支持：

• 可靠的配置版本控制。
• 高度一致性，因為文件在您每次部署時都會生成相同的環(huán)境（與應用程序源代碼生成相同的應用程序二進制文件的方式相同）。

一旦團隊向 Git 存儲庫提交更改，DevOps 管道會自動部署基礎(chǔ)架構(gòu)更新，無需人工干預。GitOps 是一個相對年輕的策略。總部位于英國的公司 Weaveworks 開發(fā)了該框架的基礎(chǔ)并于 2017 年創(chuàng)造了該術(shù)語。從那時起，GitOps 成為需要可靠且可擴展的基礎(chǔ)架構(gòu)的用例的首選實踐，例如：

• 云原生架構(gòu)。
• 任何涉及Kubernetes 的基礎(chǔ)設(shè)施。
• 微服務架構(gòu)。
• 具有持續(xù)交付功能的管道，可自動將更改部署到生產(chǎn)中。
• 混合和多云部署。

GitOps 提供高度以開發(fā)人員為中心的體驗。基礎(chǔ)設(shè)施管理發(fā)生在與應用程序開發(fā)相同的版本控制系統(tǒng)中，使團隊能夠在中央位置進行協(xié)作，同時受益于 Git 的內(nèi)置功能。

GitOps 和 DevOps 有什么區(qū)別

雖然 GitOps 和 DevOps 之間有很多重疊，但這是兩個不同的概念：

• DevOps 是一種整合開發(fā) (Dev) 和 IT 運營 (Ops) 團隊工作的文化。DevOps 工具和實踐打破了 Dev 和 Ops 之間的孤島，同時提高了代碼質(zhì)量并縮短了 SDLC。
• GitOps 是 DevOps 的一個子集，專門專注于通過 Git 自動化基礎(chǔ)設(shè)施管理。GitOps 是 IaC 發(fā)展的下一步，IaC 本身起源于DevOps 最佳實踐。

以下是 GitOps 和 DevOps 之間的其他一些顯著差異：

• GitOps 是一個專門的框架，而 DevOps 更像是一種哲學，需要對公司創(chuàng)建軟件的方式進行根本性的改變。
• DevOps 不需要使用任何特定工具。GitOps 要求團隊使用 Git（盡管您有多種其他工具可以與 Git 一起使用）。
• 一些 DevOps 管道具有用于部署的手動觸發(fā)器。使用 GitOps，觸發(fā)器始終是自動的，并且基于對 Git 存儲庫的更改。
• 您可以在沒有 GitOps 的情況下?lián)碛?DevOps，但反之則不然。

DevOps 和 GitOps 都適用于任何類型的基礎(chǔ)架構(gòu)，但它們的優(yōu)勢在云計算和裸機云環(huán)境中才能真正感受到。這兩種策略都要求團隊熟悉 IaC，而且都嚴重依賴自動化來加快流程并在問題影響最終用戶之前解決問題。

GitOps 是如何工作的？

GitOps 團隊使用Terraform 或 Ansible等工具以聲明方式配置系統(tǒng)。這種方法側(cè)重于結(jié)果（期望的狀態(tài)）而不是達到結(jié)果的確切步驟。這是一個簡化的命令式語句（與聲明式方法相反）的樣子：

• 在 XZY 機器上安裝以下依賴項。
• 從 XYZ 網(wǎng)站下載代碼。
• 將代碼移至此目錄。
• 對以下機器再重復此過程四次。

這個過程的聲明版本會簡單地寫成：以下五臺機器有來自這個 URL 的軟件，安裝在這個目錄中。您描述目標環(huán)境的所需狀態(tài)，系統(tǒng)會自動根據(jù)請求進行調(diào)整。

GitOps 團隊將所有具有聲明狀態(tài)的文件存儲在一個 Git 存儲庫中。在 Git 中存儲文件可以實現(xiàn)版本控制，幫助團隊跟蹤基礎(chǔ)架構(gòu)隨時間的變化。版本控制也有助于：

• 故障排除。
• 審計。
• 回滾到以前的狀態(tài)。

一旦團隊對存儲庫進行了更改，CI 管道就會驗證配置文件并運行自動化測試，之后任何員工都可以審查和批準提交。然后更新通過 CD 管道合并到主分支。

GitOps 提供了兩種將更改應用到生產(chǎn)環(huán)境的主要方法：

• Pull 方法：系統(tǒng)持續(xù)監(jiān)控 Git 存儲庫的更新。如果有變化，系統(tǒng)會提取新配置并將其應用于基礎(chǔ)架構(gòu)。
• 推送方式（無代理）：開發(fā)人員對 Git 存儲庫進行更改，系統(tǒng)立即觸發(fā)拉取更改并將其應用到基礎(chǔ)設(shè)施。

最后，收斂機制將存儲庫中的更新應用到生產(chǎn)集群。編排器將集群的當前狀態(tài)與 Git 中的更新進行比較并進行更改，直到實際狀態(tài)和所需狀態(tài)相同。

如何開始使用 GitOps

如果您的團隊已經(jīng)使用 Git 作為其 SCM 工具，并且已正確設(shè)置 DevOps 管道，那么實施 GitOps 很簡單。你應該做的就是：

• 將所有基礎(chǔ)架構(gòu)代碼移動到專用的 Git 存儲庫中。
• 配置CI/CD 管道，使存儲庫成為交付管道的一部分。

如果您的組織在 DevOps 成熟度等級上較低并且不使用版本控制，請從設(shè)置Git 存儲庫開始。Git 與平臺無關(guān)，因此請選擇您熟悉的任何本地或基于云的存儲庫。以下是一些受歡迎的選項：

• GitHub。
• 位桶。
• Azure 存儲庫。
• GitLab。

在聲明式編程、Git 的內(nèi)置功能和 IaC 方面培訓您的團隊。嘗試引進一些具有 GitOps 實踐經(jīng)驗的新專家，同時為現(xiàn)有員工組織培訓課程。接下來，您必須設(shè)置一個 CI/CD 管道平臺來自動執(zhí)行交付過程。管道必須跟蹤對 Git 存儲庫的更改并自動將它們部署到環(huán)境中。使用您的團隊熟悉的工具。一般來說，Jenkins和 CircleCI 是任何 Git 存儲庫的絕佳選擇。BitBucket Pipeline 和 GitLab Pipelines 需要它們自己的存儲庫。

一旦 CI/CD 管道啟動并運行，您就需要一個 GitOps 操作員。該機制充當管道和實際系統(tǒng)之間的“中間人”。三個最受歡迎的選項是：

• Kubernetes 運營商。
• Azure 服務運營商。
• Terraform 云運營商。

操作員確保實際和期望的環(huán)境狀態(tài)相匹配。該機制還提供持續(xù)監(jiān)控，以維護您的基礎(chǔ)架構(gòu)的理想狀態(tài)。

GitOps 的好處

以下是在貴公司采用 GitOps 的主要好處：

• 簡化的基礎(chǔ)架構(gòu)管理： GitOps 使團隊能夠?qū)⒒A(chǔ)架構(gòu)作為整個 DevOps 流程的一部分進行管理。借助CI/CD 工具和自動化部署，您可以快速測試和部署更改。
• 提高可靠性：所有基礎(chǔ)架構(gòu)更改都經(jīng)過全面審查和測試。經(jīng)過良好測試的更新顯著降低了出錯和停機的可能性。
• 更快的部署：一旦更新合并到主分支，就會自動部署基礎(chǔ)設(shè)施。這樣的設(shè)置減少了部署更改所需的時間，使團隊能夠更快、更頻繁地發(fā)布新功能。
• 快速回滾： Git 的版本控制使團隊能夠根據(jù)需要恢復和回滾。如果新更改破壞了集群中的某些內(nèi)容，您可以輕松解決問題。
• 授權(quán)開發(fā)人員：開發(fā)團隊可以執(zhí)行傳統(tǒng)上留給 ITOps 的任務。如果開發(fā)人員希望部署新應用程序或更改現(xiàn)有應用程序，他們所做的只是更新存儲庫，自動化流程會處理其余部分。
• 更多的團隊間協(xié)作：就像 DevOps 一樣，GitOps 需要開發(fā)人員、運營團隊和其他 IT 利益相關(guān)者之間的協(xié)作。
• 減少配置漂移的可能性： Git 為配置文件的更改提供完整的審計跟蹤。環(huán)境高度一致，您可以降低配置漂移的風險。
• 完整的 可聽性： Git 允許開發(fā)人員隨著時間的推移跟蹤基礎(chǔ)架構(gòu)。每當出現(xiàn)故障或出現(xiàn)意外行為時，這種關(guān)于誰對集群做了什么以及何時做了什么的審計跟蹤就很有價值。
• 合規(guī)性：使用聲明性基礎(chǔ)架構(gòu)即代碼可以更輕松地實現(xiàn)整個交付管道的合規(guī)性。
• 安全提升： GitOps 使團隊能夠?qū)嵤┗?Git 的安全策略并集中管理。更新在合并到主分支之前得到徹底審查并需要批準，這降低了錯誤或惡意代碼的危險。

GitOps 缺點

雖然 GitOps 提供了一系列好處，但您必須牢記一些潛在的缺點。以下是采用 GitOps 的主要問題：

• 難以設(shè)置： GitOps 的最大挑戰(zhàn)是流程的初始設(shè)置。這種做法需要緊密集成和大量自動化，而這通常很難正確設(shè)置。
• 額外的復雜性： GitOps 要求團隊采用新的工作流程，如果您不熟悉 Git 和 DevOps 實踐，這將是一項挑戰(zhàn)。許多采用者必須在招聘和員工培訓方面投入大量資金，以應對陡峭的學習曲線。
• 兼容性問題：一些應用程序不適合 GitOps。許多需要人工干預或?qū)ｉT部署流程的遺留系統(tǒng)很難（甚至不可能）與 GitOps 集成。
• 抵制變革：采用 GitOps 需要向協(xié)作、自動化和持續(xù)改進進行重大的文化轉(zhuǎn)變。許多團隊對這一變化并不熱心，這可能會在采用 GitOps 期間和之后引起問題。
• 確保 Git 安全：由于 Git 是唯一的真實來源，該平臺的存儲庫成為網(wǎng)絡攻擊的主要目標。您必須控制對配置文件的訪問以防止數(shù)據(jù)泄露。

GitOps 正在取代 DevOps 嗎？

不，GitOps 不會取代 DevOps，也不會嘗試這樣做。GitOps 旨在取代嚴重依賴手動任務和測試的老式基礎(chǔ)設(shè)施管理。公司將 GitOps 與其他 DevOps 實踐和工具結(jié)合使用，以實現(xiàn)更高水平的自動化并加快上市時間。GitOps 通過以下方式支持 DevOps 計劃：

• 靈活且可擴展的基礎(chǔ)架構(gòu)，使團隊更加敏捷。
• 跟蹤、回滾和審核更改的能力，這大大簡化了團隊解決問題的方式。
• 進一步激勵開發(fā)人員、ITOps 專家和其他員工在配置管理方面進行協(xié)作。
• 能夠自動部署和管理基礎(chǔ)設(shè)施，同時確保所有環(huán)境的一致性。

您的團隊和工作流程是否適合 GitOps？

GitOps 并不是每個團隊和項目的正確選擇。一些公司認為依賴單一工具和自動構(gòu)建基礎(chǔ)設(shè)施并不理想。但是，如果您的團隊擁有必要的專業(yè)知識并且您已經(jīng)投資于 DevOps，那么采用 GitOps 是不二之選。該實踐將所有耗時的手動基礎(chǔ)設(shè)施管理任務轉(zhuǎn)化為自動化管道，從而提高基礎(chǔ)設(shè)施的可見性、可靠性和穩(wěn)定性。