【51CTO.com快譯】如今，許多團(tuán)隊(duì)都在各種項(xiàng)目中爭相使用著諸如：版本控制、代碼審查、以及CI/CD管道等，與DevOps有關(guān)的優(yōu)秀實(shí)踐。不過，您是否注意到，這些方法主要針對的是軟件開發(fā)生命周期中的自動(dòng)化。而在涉及到基礎(chǔ)架構(gòu)的設(shè)置和部署時(shí)，項(xiàng)目團(tuán)隊(duì)仍然主要依賴的是手動(dòng)的過程。

[[355786]]

對此，GitOps提供了一套管理基礎(chǔ)架構(gòu)的自動(dòng)化方法。項(xiàng)目團(tuán)隊(duì)可以借助GitOps，并通過使用各種聲明文件，將基礎(chǔ)架構(gòu)編寫為代碼(infrastructure as code，IaC)，進(jìn)而自動(dòng)化配置的過程。也就是說，我們可以像存儲應(yīng)用程序的開發(fā)代碼那樣，將基礎(chǔ)架構(gòu)存儲放在Git存儲庫中，以提高整體的交付能力和產(chǎn)品質(zhì)量。

GitOps的工作原理

GitOps的概念最初是由Kubernetes管理公司--Weaveworks(請參見https://www.weave.works/)提出的。眾所周知，基于容器的應(yīng)用往往比較復(fù)雜，而且難以進(jìn)行配置和管理。因此，GitOps主要針對的是：在Kubernetes背景下，如何將編排平臺轉(zhuǎn)換到運(yùn)行在容器中的微服務(wù)上，并采用DevOps領(lǐng)域的成熟技術(shù)，來協(xié)助簡化該過程。下面我們將深入討論GitOps的各個(gè)主要組成部分：

基礎(chǔ)架構(gòu)即代碼(IaC)

如前所述，IaC可以通過將各種聲明性文件存儲為代碼，進(jìn)而實(shí)現(xiàn)基礎(chǔ)架構(gòu)的配置和管理。據(jù)此，通過利用IaC和版本控制，項(xiàng)目團(tuán)隊(duì)可以優(yōu)化當(dāng)前的各項(xiàng)操作進(jìn)程。此處提到的聲明式(Declarative)，意味著您的配置將不再是一組命令，而是對某種預(yù)期狀態(tài)的聲明。例如，在Kubernetes中，您可以在清單文件(manifest)中定義服務(wù)所需的Pod數(shù)量。系統(tǒng)將通過自行處理，獲取所需的容器編號，而無需工程師額外編寫命令腳本。

在此，任何符合聲明性模型的云原生軟件，都可以被視為代碼。通常，我們會(huì)將各種所需的狀態(tài)聲明為代碼，并通過系統(tǒng)應(yīng)用的更改，以自動(dòng)化的方式實(shí)現(xiàn)目標(biāo)狀態(tài)。例如：我們可以使用諸如AWS CloudFormation之類的聲明性工具，來編寫AWS的基礎(chǔ)架構(gòu)。

拉取請求(Pull Requests)

GitOps概念背后的主要思想是：版本控制系統(tǒng)是唯一的來源。我們既可以將Git用作應(yīng)用代碼的變更管理系統(tǒng)，通過拉取請求來實(shí)現(xiàn)各項(xiàng)操作性的變更，又可以將其用于基礎(chǔ)架構(gòu)的代碼上，以便將整個(gè)聲明文件集中于一處。

在應(yīng)用開發(fā)的工作流中，我們需要將某個(gè)主分支作為發(fā)布分支。在此基礎(chǔ)上，開發(fā)人員會(huì)從主分支處創(chuàng)建各個(gè)功能性分支，以便開發(fā)出特定的功能或故事線。而在功能性分支上，一旦完成了更改，他們會(huì)通過創(chuàng)建拉取請求的方式，重新合并回主分支。這樣一來，我們就可以在方便實(shí)現(xiàn)協(xié)作的同時(shí)，透明地獲悉到誰在何處進(jìn)行何種更改。而且，由于所有更改都是在Git處被提交的，因此這對于開發(fā)團(tuán)隊(duì)從根本原因處進(jìn)行問題的跟蹤，也是非常實(shí)用的。

可見，創(chuàng)建拉取請求的好處在于，我們可以讓代碼在被集成到代碼庫的另一個(gè)分支之前，事先經(jīng)歷代碼的審查過程。而代碼審查恰好能夠阻止各種不良的代碼，進(jìn)入測試或生產(chǎn)環(huán)境。顯然，這對于故障的消除，以及基礎(chǔ)架構(gòu)代碼而言，都是非常重要的。

Git的組成

GitOps并不依賴于任何工具或技術(shù)。它可以與諸如：GitHub、BitBucket或GitLab等，任何基于Git的系統(tǒng)協(xié)同使用。

而在部署過程中，GitOps至少需要兩個(gè)存儲庫，即：包含了應(yīng)用源代碼、及其部署清單的應(yīng)用程序存儲庫;和使用著每個(gè)環(huán)境的聲明性規(guī)范描述的，包含了整個(gè)系統(tǒng)目標(biāo)狀態(tài)的環(huán)境配置存儲庫。您可以在代碼存儲庫中將目標(biāo)環(huán)境定義并描述為開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境、或是包含了運(yùn)行著特定版本的應(yīng)用和基礎(chǔ)架構(gòu)服務(wù)的環(huán)境。

CI/CD

要實(shí)現(xiàn)完整的GitOps，您勢必需要一個(gè)CI/CD管道，以實(shí)現(xiàn)Git存儲庫在每次發(fā)生更改時(shí)，開發(fā)團(tuán)隊(duì)都能將對應(yīng)的基礎(chǔ)架構(gòu)變更交付到指定的環(huán)境中。該自動(dòng)交付管道能夠?qū)it的拉取請求連接到編排系統(tǒng)中，以便通過請求來觸發(fā)管道，并讓編排系統(tǒng)執(zhí)行指定的任務(wù)。

一般而言，GitOps有兩種可能的部署策略：推送管道和拉取管道。您可以根據(jù)當(dāng)前架構(gòu)需要部署的實(shí)際環(huán)境，在兩者間做出選擇。下面我們來具體看看兩種策略的各種特點(diǎn)：

推送管道(Push Pipelines)

目前，許多流行的CI/CD工具都在使用這種策略。開發(fā)人員通常將應(yīng)用程序的源代碼、及其部署清單存儲在一個(gè)存儲庫中。當(dāng)應(yīng)用代碼發(fā)生變更時(shí)，管道將觸發(fā)容器映像的構(gòu)建，并將變更推送到相應(yīng)的環(huán)境中。由于該策略支持任何類型的基礎(chǔ)架構(gòu)，因此它具有較大的靈活性。不過，其缺點(diǎn)是：它會(huì)賦予CI/CD工具對于目標(biāo)環(huán)境的寫入權(quán)限。

基于推送的DevOps部署

拉取管道(Pull Pipelines)

在開發(fā)者社區(qū)中，人們普遍認(rèn)為：對于GitOps的拉取管道方法是一種更安全的策略。這種方法引入了操作符(operator)的概念。它是管道和業(yè)務(wù)流程工具之間的組件。操作符能夠不斷將環(huán)境存儲庫中的目標(biāo)狀態(tài)，與已部署的基礎(chǔ)架構(gòu)的實(shí)際狀態(tài)，進(jìn)行比較。如果操作符檢測到任何修改，那么它就會(huì)更改基礎(chǔ)架構(gòu)，以適應(yīng)環(huán)境存儲庫。同樣地，它也可以監(jiān)視鏡像注冊表，以識別出需要部署的鏡像新版本。

基于拉取的DevOps部署

可見，在GitOps中，只有在環(huán)境存儲庫中出現(xiàn)修改時(shí)，對應(yīng)的環(huán)境才會(huì)更新。相反，如果已實(shí)施的基礎(chǔ)架構(gòu)在環(huán)境存儲庫中并未定義任何方式的修改，那么系統(tǒng)將會(huì)自動(dòng)還原。

在實(shí)際項(xiàng)目中，大多數(shù)應(yīng)用程序都會(huì)同時(shí)涉及到多個(gè)環(huán)境。對此，GitOps允許您創(chuàng)建多個(gè)管道，以同時(shí)更改多個(gè)環(huán)境存儲庫。當(dāng)然，您也可以在環(huán)境存儲庫中使用單獨(dú)的分支，來管理多個(gè)環(huán)境。我們既可以通過將操作符部署到生產(chǎn)環(huán)境中，來對單個(gè)分支的修改及時(shí)做出反應(yīng)，又可以通過部署到測試環(huán)境中，來響應(yīng)另一個(gè)分支。

GitOps的優(yōu)勢

由于GitOps專注于Git工作流、IaC、CI/CD管道，不可變服務(wù)器(immutable servers)、跟蹤、以及可觀測性等優(yōu)秀實(shí)踐模型，因此它代表了對于Kubernetes云原生應(yīng)用管理的高級狀態(tài)。據(jù)此，開發(fā)團(tuán)隊(duì)可以從如下方面受益：

簡化持續(xù)部署

顧名思義，持續(xù)部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味著更快、更頻繁的部署。通過GitOps，部署操作符提供了必要的結(jié)構(gòu)和自動(dòng)化，而且這一切都在版本控制系統(tǒng)中發(fā)生，因此我們無需各種工具，便可管理系統(tǒng)的狀態(tài)、停機(jī)時(shí)間、上游/下游依賴關(guān)系、以及其他與組織相關(guān)的流程。

此外，GitOps不但提高了項(xiàng)目團(tuán)隊(duì)的生產(chǎn)率，而且加快了他們的平均部署時(shí)間(Mean-time-to-deployment，MTTD)。有證據(jù)表明，自動(dòng)化持續(xù)部署能夠確保團(tuán)隊(duì)每天觸發(fā)30到100次以上的變更，并將生產(chǎn)環(huán)境的性能平均提高2到3倍。

縮短平均修復(fù)時(shí)間(Mean-time-to-repair，MTTR)

MTTR是衡量DevOps團(tuán)隊(duì)績效的一項(xiàng)關(guān)鍵指標(biāo)(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系統(tǒng)中的所有修改，并且能夠?qū)崿F(xiàn)自動(dòng)化的管理，因此，開發(fā)團(tuán)隊(duì)能夠全面了解目標(biāo)環(huán)境中的變化，輕松發(fā)現(xiàn)和修復(fù)錯(cuò)誤，從而顯著降低MTTR。

簡化Kubernetes管理

在無需透徹了解Kubernetes的情況下，開發(fā)人員可以使用Git等較為熟悉的工具，更加輕松地管理Kubernetes的升級和各項(xiàng)功能。據(jù)此，新加入的成員也能夠在幾天時(shí)間快速上手Kubernetes。

全面掌握并標(biāo)準(zhǔn)化工作流

由于GitOps提供了一站式的應(yīng)用程序、軟件、以及針對Kubernetes修改的框架，因此開發(fā)團(tuán)隊(duì)可以清晰地洞悉整個(gè)項(xiàng)目的端到端工作流，并能通過Git來完全復(fù)現(xiàn)日常的業(yè)務(wù)運(yùn)營活動(dòng)。

GitOps的實(shí)現(xiàn)

• 建立穩(wěn)定的代碼審查與測試過程。通過仔細(xì)地檢查代碼的更改，我們能夠及時(shí)發(fā)現(xiàn)諸如全局變量的添加等操作，并且可以通過提交拉取請求(而非直接提交更改的方式)，來驗(yàn)證代碼。而在拉取請求被檢查與合并之后，管道才會(huì)被觸發(fā)。此舉在避免發(fā)布錯(cuò)誤的代碼的同時(shí)，有效地保持了高標(biāo)準(zhǔn)的代碼，以及系統(tǒng)后續(xù)的穩(wěn)定性。
• 持續(xù)測試。合并到GitOps中，往往意味需要通過高級的自動(dòng)化機(jī)制，對待發(fā)布的應(yīng)用程序進(jìn)行徹底的測試。有了GitOps，我們不但能夠相對輕松地實(shí)現(xiàn)回滾，還能夠通過良好的測試用例，保障代碼的質(zhì)量和可靠性。
• 專注監(jiān)控。GitOps允許開發(fā)人員重復(fù)各項(xiàng)操作流程，改進(jìn)、發(fā)布并回顧各種可追溯的系統(tǒng)狀態(tài)。而通過專注于監(jiān)控，我們可以識別并防止任何意外的漂移(drift)、以及系統(tǒng)配置的變更。因此，在開始使用GitOps之前，開發(fā)團(tuán)隊(duì)有必要檢查自己的監(jiān)控水平，以及處理變更的能力。
• 擁抱文化。作為目前在開發(fā)領(lǐng)域的優(yōu)秀戰(zhàn)略，DevOps文化能夠促進(jìn)團(tuán)隊(duì)的共同協(xié)作，更有效地管理基礎(chǔ)架構(gòu)的穩(wěn)定性，更快、更流暢地執(zhí)行應(yīng)用程序。而GitOps又能夠讓我們在此基礎(chǔ)上，進(jìn)一步理解開發(fā)和運(yùn)營的協(xié)同價(jià)值，提供一整套自動(dòng)化的管理方法。

小結(jié)

作為一種非常好的工作流模式，GitOps不但可以幫助我們有效地處理云基礎(chǔ)架構(gòu)，還能夠?yàn)楣こ虉F(tuán)隊(duì)提供：更好的協(xié)調(diào)性、透明度、穩(wěn)定性、以及系統(tǒng)耐用性等方面的諸多好處。

原文標(biāo)題：GitOps – DevOps for Infrastructure Automation，作者：Sara Miteva

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】