如何運用DevOps實現基礎設施自動化

這篇文章主要介紹“如何運用DevOps實現基礎設施自動化”，在日常操作中，相信很多人在如何運用DevOps實現基礎設施自動化問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何運用DevOps實現基礎設施自動化”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

GitOps 提供一種自動化基礎設施管理方法，已經在眾多團隊中得到應用的 DevOps 最佳實踐——包括版本控制、代碼審查以及 CI/CD 流水線——都將被囊括于其中。目前，許多公司都在采用 DevOps，看中的正是它在提高生產率和軟件質量方面擁有的巨大潛力。在這一過程中，我們已經找到了自動化軟件開發生命周期的方法。但是，當涉及到基礎設施的設置和部署時，手動操作的比重仍然相當可觀。有了 GitOps，團隊就可以自動化基礎設施配置過程。這是由于在 GitOps 方法中，我們能夠使用聲明將基礎設施編寫為代碼（IaC），而后像存儲應用程序開發代碼一樣將基礎設施即代碼存儲在 Git repo 當中。

GitOps 如何發揮作用？

GitOps 的概念最初是由 Kubernetes 管理公司 Weaveworks 所提出，因此關于 GitOps 的討論主要是在 Kubernetes 的背景下進行的。隨著整體設施轉向運行在容器內的微服務架構，我們自然需要更多可行的編排平臺作為支撐。事實上，基于容器的應用程序也往往擁有極為復雜且難以管理的配置體系。GitOps 則通過應用在 DevOps 領域已經得到實際驗證的技術，幫助我們簡化了這一過程。如今，這一思路已經在 DevOps 支持者中得到廣泛認可，也代表著 IaC 概念的升級模型。其中包含三大主要組成部分：

• 基礎設施即代碼

• Pull 請求

• CI/CD

下面具體來看。

基礎設施即代碼

IaC 是一種將基礎設施以聲明文件的形式進行配置和管理，并將其存儲為代碼的實踐。通過利用 IaC 和版本控制，團隊即可輕松優化所有的運營過程。GitOps 以 IaC 的聲明性模型為核心，同時也為 Kubernetes 提供了良好的施展平臺。聲明性意味著配置更多關注指向預期狀態的聲明，而不是一組具體命令。例如，在 Kubernetes 中，你可以在 manifest 中定義服務所需的 Pod 數量。以此為基礎，系統將根據服務的運行狀態自動為其提供 Pod，而不再由工程師編寫固定的 Pod 配置數量。任何符合聲明式模型的云原生軟件都可以被視為代碼。我們使用 AWS CloudFormation（一種聲明性工具）來編寫 AWS 基礎設施，借此實現基礎設施即代碼原則。所需的狀態將被聲明為代碼形式，系統則應用更改以自動達到這一目標狀態。當然，聲明式模型并不是實現 GitOps 的唯一途徑。大家也可以使用命令式定義環境實現相同的運營效果。

Pull 請求

GitOps 概念背后的核心思路，是將版本控制系統視為單一的客觀來源。我們使用 Git 作為應用程序代碼的變更管理系統，也可以將其用于基礎架構代碼。所以所有的聲明文件都托管在統一位置以供協作使用。在此基礎之上，我們得以使用 Git 的關鍵概念——操作更改的 pull 請求。在應用程序開發工作流中，我們使用一個主分支作為發布分支。開發人員在主分支內創建功能分支。在開發一項特定的功能或故事之后，我們創建一個 pull 請求以將其合并回主分支。同樣的方法也能在基礎設施代碼中便捷起效。通過創建 pull 請求，我們可以保證代碼在被集成至代碼庫的另一個分支之前，首先經過完整的代碼審查流程。代碼審查可以阻止低質量代碼進入測試或生產環境，這一點對于基礎架構代碼來說尤為重要。通過代碼審查獲得正式的批準，也將有助于后續的審核和故障排查工作。

Git 組織

GitOps 的部署過程至少需要兩個 repo：應用程序 repo 與環境配置 repo。前者包含應用程序的源代碼及其部署 manifest；后者則包含了整個系統所需的狀態，該狀態使用聲明性規范來對環境中的各項要素加以描述。你可以在代碼 repo 中將環境描述為開發、測試和生產環境，同時包含可以在該環境的特定版本中運行的應用程序和基礎設施服務。在基礎設施的情況下，主分支可以表示一個環境。我們可以在功能分支中實現這些更改，而后創建一個 pull 請求來合并主分支中的變更。通過這種方式，我們可以在實現協作的同時，以更加透明的方式了解誰執行了哪些更改。因為所有的更改都是在 Git 中提交完成，因此這也有利于跟蹤引發問題的根本原因。GitOps 適用于任何基于 Git 的系統，包括 GitHub、BitBucket 或 GitLab。其不依賴于任何特定工具或技術。

CI/CD

為了建立完整的 GitOps 實現，你還需要一條 CI/CD 流水線。通過使用自動化的交付流水線，每當 Git 存儲庫中發生更改時，你都可以將基礎設施更改交付到指定環境當中。這條流水線將你的 Git pull 請求連接到業務流程系統。當你使用 pull 請求觸發流水線時，業務流程系統將相應執行該任務。GitOps 的部署策略有兩種方式：push 與 pull 流水線。二者的區別，主要體現在構建基礎設施時所采取的環境部署方式之上。

許多流行的 CI/CD 工具都在使用這種策略。我們將應用程序的源代碼及其部署 manifest 存儲在一個 repo 當中。當應用程序代碼中發生新的更新時，構建流水線將觸發。流水線將構建容器鏡像并將更改推送到環境。這種策略帶來了更高的靈活性，足以支持任意類型的基礎設施。當然，這種方法也有缺點，即允許 CI/CD 工具直接訪問你的環境。

社區普遍認為，pull 流水線方法對 GitOps 來說是一種更為安全的實踐方案。這種方法引入引入了操作符。操作符屬于流水線和業務流程工具之間的組件，它會不斷將環境 repo 中的目標狀態與已部署基礎設施中的實際狀態進行比較。一旦檢測到任何更改，則操作符會更改基礎設施以適應環境 repo。此外，它還可以監控鏡像倉庫，識別待部署的新版本鏡像。正是這一切，讓 GitOps 變得如此特別。在 GitOps 中，只有在環境 repo 中發生了更改時，才會引發環境更新。如果實現的基礎設施以環境 repo 中未經定義的任何其他方式發生更改，系統將恢復所做的任何修改。大多數應用程序可能需要同時使用多個環境。GitOps 允許您創建多個可以更改環境 repo 的流水線。您可以在環境 repo 中使用單獨的分支以管理更多環境。面對分支變更，運維人員可以在響應中將此項變更部署到生產環境當中，同時將來自另一分支的其他變更部署到測試環境。  

GitOps 的優勢是什么？

DevOps 最佳實踐

GitOps 是一套專注于現有 Git 工作流、IaC、CI/CD 流水線、不可變服務器、跟蹤與可觀察性最佳實踐的模型，也代表著 Kubernetes 在云原生應用程序管理領域的先進的理念。因此，其技術棧與操作體驗能夠切實為企業用戶帶來諸多助益。

持續部署——簡化

持續部署意味著更快、更頻繁的部署節奏。出于多種不同考量，例如系統的有狀態性、宕機彈性、上游/下游的依賴關系，以及組織內常見的其他過程與依賴項，很多朋友可能發現越來越難以建立適當的持續部署機制。GitOps 不僅能夠實現持續部署，同時也讓大家擺脫了對大量工具方案的單獨管理——這是因為所有操作都發生在版本控制系統之內。作為另一大助力，部署操作符則負責提供結構和自動化支持。這也提高了生產力并帶來更快的 MTTD（平均部署時間）。自動化持續部署確保團隊每天可以交付 30-100 倍以上的更改，將平均生產效能提高 2-3 倍。

Rancher 2.5 通過 Rancher 持續交付（Continuous Delivery）簡化了部署和管理。這是一項全新的功能，通過使用 Git 倉庫自動存儲和管理應用程序和配置信息，以確保部署的一致性，大大減輕了客戶的負擔，從而簡化跨私有云、公有云、混合云或多云環境的部署流程。

Rancher 于 2020 年推出了海量集群管理項目 Fleet，這個項目成為了 Rancher 持續交付的引擎。Fleet 是一個 Kubernetes 集群控制器，旨在解決全球內成千上萬集群的挑戰。

低 MTTR（平均修復時間）

MTTR 是 DevOps 團隊需要衡量的關鍵指標之一。在微服務架構中，即使是極微小的問題也可能難以修復。由于 GitOps 將所有更改保存在版本控制系統中，同時輔以自動化管理手段，因此有望顯著縮短 MTTR。你可以全面了解環境的變化進程，同時極大降低錯誤恢復難度。

簡化 Kubernetes 管理

即使對 Kubernetes 不甚了解，開發人員可以使用熟悉的工具(如 Git)輕松獲取 Kubernetes 升級與功能實現。新手嵌入式開發人員能夠很快跟上進度，將原本需要數月的適應期壓縮到幾天時間。

改進企業整體的標準化水平

你可以在整個企業中建立起透明的端到端工作流，這要歸功 GitOps 提供的用于呈現應用程序、軟件和 Kubernetes 附加組件修改的呈現框架。Git 還能夠全面重現你的各項操作活動。

應用 GitOps 的先決條件

建立穩定的代碼審查與測試過程

深入檢查代碼更改將幫助我們準確識別某些重要操作，例如添加全局變量，借此防止低質量代碼被發布到測試甚至生產環境當中。以此為基礎，您可以通過 pull 請求提交驗證過的代碼，且嚴格禁止開發人員直接提交更改。一旦 pull 請求完成審查與合并，即可觸發流水線。這是也維護高標準代碼、進而增強系統穩定性的第一步。

測試

GitOps 的介入意味著整個自動化水平都將提升到新的高度，這也要求我們對流水線發布的應用程序進行徹底測試。盡管 GitOps 能幫助我們相對輕松地完成回滾，但發布經過良好測試的高質量代碼才是真正提升進程可靠性的最佳途徑。

監控為王

GitOps 能夠重播操作過程，持續跟蹤系統狀態并加以改進，最終據此執行發布與回滾。嚴格的監控體系可以幫助你識別并防止配置中出現任何非預期的漂移與系統更改。因此，在開始使用 GitOps 之前，請檢查你的監控技能并著手加強，確保其有能力處理這種變化。

擁抱新文化

傳統的流程約束以及較長的發布時間只會拖慢業務節奏。全面擁抱 DevOps 文化，意味著我們應當全面利用最佳戰略并幫助團隊理解開發和運維行動的價值。與此同時，開發與運維團隊必須聯手協作，建立起整體穩定的基礎設施，更快速、更順暢地運行應用程序，進而提升系統管理效率。而 DevOps 文化的欠缺將嚴重阻礙我們享受 GitOps 帶來的好處。

為什么采用 GitOps？

GitOps 是一種強大的工作流模式，可以幫助您高效治理云基礎設施。GitOps 可以為工程團隊帶來諸多優勢，極大增強系統的協調能力、透明度、穩定性與持久性。

到此，關于“如何運用DevOps實現基礎設施自動化”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！