1.2 GitOps帶給開(kāi)發(fā)者的好處

GitOps為開(kāi)發(fā)人員提供了許多好處，因?yàn)樗试S開(kāi)發(fā)者使用與管理軟件開(kāi)發(fā)過(guò)程大體相同的方式來(lái)處理基礎(chǔ)設(shè)施配置和代碼部署，并且使用的是熟悉的工具：Git。

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

基礎(chǔ)設(shè)施即代碼（IaC）是GitOps的基本范式。運(yùn)行應(yīng)用程序的基礎(chǔ)設(shè)施的配置是通過(guò)自動(dòng)化過(guò)程而非手動(dòng)步驟來(lái)完成的[4]。在實(shí)踐中，IaC意味著通過(guò)編碼進(jìn)行基礎(chǔ)設(shè)施的變更，并將基礎(chǔ)設(shè)施的源代碼存儲(chǔ)在版本控制系統(tǒng)中。讓我們來(lái)看看IaC的顯著好處：

□可重復(fù)性：所有有過(guò)手動(dòng)配置基礎(chǔ)設(shè)施經(jīng)驗(yàn)的人都同意該過(guò)程既耗時(shí)又容易出錯(cuò)。IaC不會(huì)忘記同一過(guò)程必須得重復(fù)多次，因?yàn)閼?yīng)用程序通常會(huì)部署到多個(gè)環(huán)境中。如果發(fā)現(xiàn)問(wèn)題，也可以通過(guò)可重復(fù)的過(guò)程更輕松地回滾到較早的工作配置，從而加快恢復(fù)。

□可靠性：自動(dòng)化過(guò)程顯著降低了發(fā)生不可避免的人為錯(cuò)誤的可能性，進(jìn)而降低了中斷的可能性。當(dāng)過(guò)程被編碼后，基礎(chǔ)設(shè)施的質(zhì)量不再取決于執(zhí)行部署的特定工程師的知識(shí)和技能。另外，基礎(chǔ)設(shè)施配置的自動(dòng)化程度也能穩(wěn)步提高。

□效率：IaC提高了團(tuán)隊(duì)的生產(chǎn)力。借助IaC，工程師的工作效率更高，因?yàn)樗麄兪褂檬煜さ墓ぞ?，例如API、軟件開(kāi)發(fā)工具包（SDK）、版本控制系統(tǒng)和文本編輯器。工程師可以使用熟悉的流程，并利用代碼審查和自動(dòng)化測(cè)試帶來(lái)的優(yōu)勢(shì)。

□節(jié)省：IaC的初始實(shí)施需要投入大量精力和時(shí)間。然而，盡管初始成本較高，但從長(zhǎng)遠(yuǎn)來(lái)看，它更具成本效益。后續(xù)環(huán)境的基礎(chǔ)設(shè)施置備將不再需要工程師把寶貴的時(shí)間浪費(fèi)在手動(dòng)配置上。由于資源置備速度快且成本低，因此無(wú)須保持未使用的環(huán)境運(yùn)行。相反，每個(gè)環(huán)境都可以按需創(chuàng)建，并在不再需要時(shí)銷(xiāo)毀。

□可見(jiàn)性：當(dāng)你定義IaC時(shí)，代碼本身就記錄了基礎(chǔ)設(shè)施該有的樣子。

IaC使開(kāi)發(fā)人員能夠生產(chǎn)更高質(zhì)量的軟件，同時(shí)節(jié)省時(shí)間和金錢(qián)。為單一環(huán)境手動(dòng)配置基礎(chǔ)設(shè)施可能更容易，但維護(hù)該環(huán)境以及應(yīng)用程序的其他數(shù)十個(gè)環(huán)境將變得越來(lái)越有挑戰(zhàn)。使用自動(dòng)化基礎(chǔ)設(shè)施配置并遵循IaC原則，能夠?qū)崿F(xiàn)可重復(fù)的部署，并防止由配置漂移或缺少依賴(lài)項(xiàng)引起的運(yùn)行時(shí)問(wèn)題。

1.2.2 自服務(wù)

如前所述，在傳統(tǒng)的運(yùn)維模式中，基礎(chǔ)設(shè)施管理由專(zhuān)門(mén)的團(tuán)隊(duì)甚至公司內(nèi)的一個(gè)獨(dú)立組織來(lái)負(fù)責(zé)。

然而，這種方法存在一個(gè)問(wèn)題：無(wú)法規(guī)?；o(wú)論有多少成員，這個(gè)專(zhuān)用團(tuán)隊(duì)很快就會(huì)成為瓶頸。在該方法下，應(yīng)用開(kāi)發(fā)人員無(wú)法自己變更基礎(chǔ)設(shè)施，取而代之的是必須提交工單、發(fā)送電子郵件、安排會(huì)議，然后就是等待。無(wú)論過(guò)程如何都存在障礙，這將導(dǎo)致許多延遲，并阻礙團(tuán)隊(duì)主動(dòng)提出基礎(chǔ)設(shè)施變更。GitOps旨在通過(guò)自動(dòng)化過(guò)程，并使其成為自服務(wù)來(lái)打破這一障礙。

相較于提交工單，當(dāng)使用GitOps模型時(shí)，開(kāi)發(fā)人員有一個(gè)可獨(dú)立工作的解決方案，并對(duì)倉(cāng)庫(kù)提交基礎(chǔ)設(shè)施聲明式配置的更改（見(jiàn)圖1.5）。基礎(chǔ)設(shè)施的變更不再需要跨團(tuán)隊(duì)的溝通，這使得應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)能夠更快地向前推進(jìn)，并有更多的自由進(jìn)行試驗(yàn)。快速且獨(dú)立地變更基礎(chǔ)設(shè)施的能力鼓勵(lì)開(kāi)發(fā)人員對(duì)其應(yīng)用程序基礎(chǔ)設(shè)施擁有所有權(quán)。開(kāi)發(fā)人員可以試驗(yàn)和發(fā)展一種能夠有效解決業(yè)務(wù)需求的設(shè)計(jì)，而無(wú)須向集中式運(yùn)維團(tuán)隊(duì)尋求解決方案。

開(kāi)發(fā)人員在做他們想做的事情時(shí)不會(huì)被完全管控，然而，這也可能會(huì)對(duì)安全性或可靠性帶來(lái)?yè)p害。因此需要對(duì)每個(gè)變更都創(chuàng)建一個(gè)拉取請(qǐng)求，拉取請(qǐng)求可由應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)的其他成員審核。接下來(lái)會(huì)進(jìn)行說(shuō)明。

GitOps的優(yōu)勢(shì)在于它允許自服務(wù)式的基礎(chǔ)設(shè)施變更，并在管控和開(kāi)發(fā)速度之間提供合理的平衡。

1.2.3 代碼審查

代碼審查是一種軟件開(kāi)發(fā)實(shí)踐，在該實(shí)踐里，會(huì)有第二雙眼睛主動(dòng)檢查代碼的更改是否存在錯(cuò)誤或遺漏，從而減少可預(yù)防的中斷。執(zhí)行代碼審查是軟件開(kāi)發(fā)生命周期中的一個(gè)自然過(guò)程，從事DevOps/GitOps的軟件工程師應(yīng)該熟悉這個(gè)過(guò)程。當(dāng)DevOps工程師可以將基礎(chǔ)設(shè)施視為代碼時(shí)，符合邏輯的下一步是在部署之前對(duì)基礎(chǔ)設(shè)施更改執(zhí)行代碼審查。當(dāng)GitOps與Kubernetes一起使用時(shí)，被審查的“代碼”可能主要是Kubernetes YAML清單或其他聲明式配置文件，而不是用編程語(yǔ)言編寫(xiě)的傳統(tǒng)代碼。

除了防止錯(cuò)誤外，代碼審查還提供以下好處：

□教授和分享知識(shí)：在審查更改時(shí)，審查者不僅有機(jī)會(huì)提供反饋，而且有機(jī)會(huì)學(xué)到一些東西。

□設(shè)計(jì)和實(shí)現(xiàn)的一致性：在審查期間，團(tuán)隊(duì)可以確保更改與整體代碼結(jié)構(gòu)保持一致，并遵循公司的代碼風(fēng)格指南。

□團(tuán)隊(duì)凝聚力：代碼審查不僅僅是為了批評(píng)和請(qǐng)求更改，這也是團(tuán)隊(duì)成員相互稱(chēng)贊、拉近距離，并確保人人充分參與的絕佳方式。

在合理的代碼審查過(guò)程中，只有經(jīng)過(guò)驗(yàn)證和批準(zhǔn)的基礎(chǔ)設(shè)施變更才會(huì)提交給主干分支，以此防止錯(cuò)誤和對(duì)運(yùn)行環(huán)境的不正確修改。代碼審查不一定需要完全由人來(lái)完成，該過(guò)程還可以運(yùn)行自動(dòng)化工具，例如代碼linter[5]、靜態(tài)代碼分析和安全工具。

注 一些用于代碼和漏洞分析的自動(dòng)化工具在第4章中介紹。

代碼審查長(zhǎng)久以來(lái)就被認(rèn)為是軟件開(kāi)發(fā)最佳實(shí)踐的關(guān)鍵部分。GitOps的核心前提是：用于應(yīng)用程序代碼的代碼審查方式，也應(yīng)該同樣嚴(yán)格地用于應(yīng)用程序運(yùn)行環(huán)境的變更。

1.2.4 Git拉取請(qǐng)求

Git版本控制系統(tǒng)提供了一種機(jī)制，在這種機(jī)制中，建議的更改可以提交到分支或復(fù)刻（fork），然后通過(guò)拉取請(qǐng)求與主干分支合并。2005年，Git引入了request-pull命令，此命令生成所有更改的可讀摘要，該摘要可以人為地以郵件形式發(fā)送給項(xiàng)目維護(hù)人員。拉取請(qǐng)求收集對(duì)倉(cāng)庫(kù)文件的所有更改，并通過(guò)差異的展示供代碼審查和批準(zhǔn)。

拉取請(qǐng)求可用于強(qiáng)制執(zhí)行合并前的代碼審查。在拉取請(qǐng)求合并到主干分支之前，可以設(shè)置控制以要求特定的測(cè)試或?qū)徟?。與代碼審查一樣，拉取請(qǐng)求是軟件開(kāi)發(fā)生命周期中一個(gè)軟件工程師早已熟練使用的過(guò)程。

圖1.6展示了典型的拉取請(qǐng)求生命周期：

1.開(kāi)發(fā)人員創(chuàng)建一個(gè)新分支并開(kāi)始處理更改。

2.當(dāng)更改準(zhǔn)備就緒后，開(kāi)發(fā)人員會(huì)發(fā)送拉取請(qǐng)求以進(jìn)行代碼審查。

3.團(tuán)隊(duì)成員審查拉取請(qǐng)求并在必要時(shí)進(jìn)一步提出更多的更改請(qǐng)求。

4.開(kāi)發(fā)人員不斷在分支中進(jìn)行更改，直到拉取請(qǐng)求獲得批準(zhǔn)。

5.項(xiàng)目維護(hù)者將拉取請(qǐng)求合并到主干分支中。在合并后，用于拉取請(qǐng)求的分支可能會(huì)被刪除。

當(dāng)用于基礎(chǔ)設(shè)施的變更審查時(shí)，該審查步驟會(huì)特別有趣。創(chuàng)建拉取請(qǐng)求后，項(xiàng)目維護(hù)人員會(huì)收到通知并審查提議的更改。因此，審閱者提出問(wèn)題、獲得答案，并可能要求進(jìn)行更多更改。這些信息通常被存儲(chǔ)以供將來(lái)參考，因此，拉取請(qǐng)求現(xiàn)在是基礎(chǔ)設(shè)施變更的活文檔。一旦發(fā)生事故，就能直接找出誰(shuí)進(jìn)行了變更以及為何應(yīng)用變更。