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

創(chuàng)新互聯(lián)公司專注骨干網(wǎng)絡(luò)服務(wù)器租用十多年，服務(wù)更有保障！服務(wù)器租用，資陽移動機(jī)房 成都服務(wù)器租用，成都服務(wù)器托管，骨干網(wǎng)絡(luò)帶寬，享受低延遲，高速訪問。靈活、實現(xiàn)低成本的共享或公網(wǎng)數(shù)據(jù)中心高速帶寬的專屬高性能服務(wù)器。

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

GitOps 如何發(fā)揮作用？

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

• 基礎(chǔ)設(shè)施即代碼

• Pull 請求

• CI/CD

下面具體來看。

基礎(chǔ)設(shè)施即代碼

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

Pull 請求

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

Git 組織

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

CI/CD

為了建立完整的 GitOps 實現(xiàn)，你還需要一條 CI/CD 流水線。通過使用自動化的交付流水線，每當(dāng) Git 存儲庫中發(fā)生更改時，你都可以將基礎(chǔ)設(shè)施更改交付到指定環(huán)境當(dāng)中。這條流水線將你的 Git pull 請求連接到業(yè)務(wù)流程系統(tǒng)。當(dāng)你使用 pull 請求觸發(fā)流水線時，業(yè)務(wù)流程系統(tǒng)將相應(yīng)執(zhí)行該任務(wù)。GitOps 的部署策略有兩種方式：push 與 pull 流水線。二者的區(qū)別，主要體現(xiàn)在構(gòu)建基礎(chǔ)設(shè)施時所采取的環(huán)境部署方式之上。

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

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

GitOps 的優(yōu)勢是什么？

DevOps 最佳實踐

GitOps 是一套專注于現(xiàn)有 Git 工作流、IaC、CI/CD 流水線、不可變服務(wù)器、跟蹤與可觀察性最佳實踐的模型，也代表著 Kubernetes 在云原生應(yīng)用程序管理領(lǐng)域的先進(jìn)的理念。因此，其技術(shù)棧與操作體驗?zāi)軌蚯袑崬槠髽I(yè)用戶帶來諸多助益。

持續(xù)部署——簡化

持續(xù)部署意味著更快、更頻繁的部署節(jié)奏。出于多種不同考量，例如系統(tǒng)的有狀態(tài)性、宕機(jī)彈性、上游/下游的依賴關(guān)系，以及組織內(nèi)常見的其他過程與依賴項，很多朋友可能發(fā)現(xiàn)越來越難以建立適當(dāng)?shù)某掷m(xù)部署機(jī)制。GitOps 不僅能夠?qū)崿F(xiàn)持續(xù)部署，同時也讓大家擺脫了對大量工具方案的單獨管理——這是因為所有操作都發(fā)生在版本控制系統(tǒng)之內(nèi)。作為另一大助力，部署操作符則負(fù)責(zé)提供結(jié)構(gòu)和自動化支持。這也提高了生產(chǎn)力并帶來更快的 MTTD（平均部署時間）。自動化持續(xù)部署確保團(tuán)隊每天可以交付 30-100 倍以上的更改，將平均生產(chǎn)效能提高 2-3 倍。

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

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

低 MTTR（平均修復(fù)時間）

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

簡化 Kubernetes 管理

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

改進(jìn)企業(yè)整體的標(biāo)準(zhǔn)化水平

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

應(yīng)用 GitOps 的先決條件

建立穩(wěn)定的代碼審查與測試過程

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

測試

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

監(jiān)控為王

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

擁抱新文化

傳統(tǒng)的流程約束以及較長的發(fā)布時間只會拖慢業(yè)務(wù)節(jié)奏。全面擁抱 DevOps 文化，意味著我們應(yīng)當(dāng)全面利用最佳戰(zhàn)略并幫助團(tuán)隊理解開發(fā)和運(yùn)維行動的價值。與此同時，開發(fā)與運(yùn)維團(tuán)隊必須聯(lián)手協(xié)作，建立起整體穩(wěn)定的基礎(chǔ)設(shè)施，更快速、更順暢地運(yùn)行應(yīng)用程序，進(jìn)而提升系統(tǒng)管理效率。而 DevOps 文化的欠缺將嚴(yán)重阻礙我們享受 GitOps 帶來的好處。

為什么采用 GitOps？

GitOps 是一種強(qiáng)大的工作流模式，可以幫助您高效治理云基礎(chǔ)設(shè)施。GitOps 可以為工程團(tuán)隊帶來諸多優(yōu)勢，極大增強(qiáng)系統(tǒng)的協(xié)調(diào)能力、透明度、穩(wěn)定性與持久性。

到此，關(guān)于“如何運(yùn)用DevOps實現(xiàn)基礎(chǔ)設(shè)施自動化”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
網(wǎng)站欄目：如何運(yùn)用DevOps實現(xiàn)基礎(chǔ)設(shè)施自動化
文章源于：http://weahome.cn/article/ijgejj.html