在軟件交付領(lǐng)域，GitOps是近期的熱門(mén)趨勢(shì)，它沿襲并擴(kuò)展了DevOps、基礎(chǔ)架構(gòu)即代碼和CI/CD等趨勢(shì)。

[[392059]]

GitOps的優(yōu)勢(shì)可以簡(jiǎn)單地歸納如下：

• 自由地審計(jì)更改
• 持續(xù)集成和交付
• 更好地控制更改管理

然而，現(xiàn)實(shí)情況卻是構(gòu)建GitOps流水線并非易事，它涉及到許多大大小小的決定，而這些決定會(huì)給實(shí)施工作帶來(lái)許多麻煩。我們將這些決定稱(chēng)為“GitOps架構(gòu)”，它可能會(huì)導(dǎo)致實(shí)施過(guò)程中面臨許多挑戰(zhàn)。

好的方面是只要有一定的規(guī)劃和經(jīng)驗(yàn)，就可以大大減少過(guò)渡到GitOps交付模式的痛苦。

在本文中，我將通過(guò)一家公司的故事來(lái)解釋其中的一些挑戰(zhàn)。這家公司從一個(gè)零散的小創(chuàng)業(yè)公司采用GitOps，成長(zhǎng)為一家規(guī)范的跨國(guó)企業(yè)。雖然這種加速成長(zhǎng)的情況很少見(jiàn)，但它確實(shí)反映了大型組織中的許多團(tuán)隊(duì)從概念驗(yàn)證，到最小可行性產(chǎn)品(minimum viable product)，再到成熟系統(tǒng)的經(jīng)驗(yàn)。

簡(jiǎn)單的開(kāi)始

如果你剛剛開(kāi)始，最簡(jiǎn)單的做法是創(chuàng)建一個(gè)單一的Git repo，將所有需要的代碼都放在里面。其中可能包括：

• 應(yīng)用程序代碼
• Dockerfile，用于構(gòu)建應(yīng)用程序鏡像
• 一些CI/CD流水線代碼(例如GitLab CI/CD或GitHub
• Actions)
• Terraform，以配置運(yùn)行應(yīng)用程序所需資源

此外，所有的更改都是直接對(duì)master進(jìn)行改動(dòng)，因此更改可以直接生效。

這一方法的主要優(yōu)勢(shì)在于你有單一的參考點(diǎn)，以及所有代碼都會(huì)緊密集成在一起。如果您的所有開(kāi)發(fā)人員都受到完全信任，并且速度就是一切，那么這一方法會(huì)持續(xù)生效。

不幸的是，隨著你的業(yè)務(wù)量不斷增長(zhǎng)，這種方法的弊端很快就會(huì)顯現(xiàn)出來(lái)。

首先，隨著越來(lái)越多的代碼被添加到代碼庫(kù)中，代碼庫(kù)規(guī)模的膨脹會(huì)使得工程師們陷入困惑，因?yàn)樗麄儠?huì)遇到更多必須解決的更改之間的沖突。如果團(tuán)隊(duì)成員大幅增長(zhǎng)，那么隨之而來(lái)的重新分配工作或合并會(huì)導(dǎo)致進(jìn)一步的混亂。

其次，如果您需要分開(kāi)控制流水線運(yùn)行，則會(huì)遇到困難。有時(shí)，您只想快速測(cè)試對(duì)代碼的更改，而不是進(jìn)行部署以實(shí)現(xiàn)完整的端到端交付。這種方法在整體性方面產(chǎn)生了越來(lái)越多需要解決的問(wèn)題，隨著這些更改的進(jìn)行可能會(huì)影響其他人的工作。

第三，隨著您的成長(zhǎng)，您可能會(huì)希望工程師和團(tuán)隊(duì)之間的責(zé)任邊界更加細(xì)化。這可以通過(guò)一個(gè)單一的repo來(lái)實(shí)現(xiàn)，并且一個(gè)repo通常是一個(gè)更清晰和更干凈的邊界。 

分離Repository

隨著業(yè)務(wù)的增長(zhǎng)，流水線會(huì)越來(lái)越擁擠，merge開(kāi)始變得痛苦。此外，您的團(tuán)隊(duì)也需要專(zhuān)業(yè)化，將不同的責(zé)任領(lǐng)域劃分給不同的成員。

所以你需要將Repo分離出來(lái)。這時(shí)，你首先要面對(duì)大量的決定，譬如repo應(yīng)該分離到什么程度?是否需要為應(yīng)用程序代碼建立一個(gè)單獨(dú)的repo?看起來(lái)是不是很合理?然后把Docker構(gòu)建的東西也一起放進(jìn)去?那這樣的分離其實(shí)沒(méi)有什么意義。

那所有團(tuán)隊(duì)的Terraform代碼呢?應(yīng)該放在一個(gè)新的repo里嗎?這聽(tīng)起來(lái)很合理，但是：新創(chuàng)建的中央“平臺(tái)”團(tuán)隊(duì)想要控制對(duì)AWS中核心IAM(身份和訪問(wèn)管理)規(guī)則定義的訪問(wèn)，而團(tuán)隊(duì)RDS配置代碼也在其中，開(kāi)發(fā)團(tuán)隊(duì)需要定期對(duì)其進(jìn)行調(diào)整。

所以你決定將Terraform分離成兩個(gè)repo：一個(gè)是“平臺(tái)”repo，一個(gè)是“特定應(yīng)用程序”repo。這就帶來(lái)了另一個(gè)挑戰(zhàn)，因?yàn)槟悻F(xiàn)在還需要分離Terraform的狀態(tài)文件。這并不是一個(gè)無(wú)法解決的問(wèn)題，但這也并不是您所習(xí)慣的快速功能交付，所以產(chǎn)品經(jīng)理將不得不解釋為什么功能請(qǐng)求所需的時(shí)間比之前更長(zhǎng)。

不幸的是，這些GitOps決策還沒(méi)有既定的最佳實(shí)踐或模式。

分離的問(wèn)題還不止于此。以前，流水線內(nèi)構(gòu)建的組件之間的協(xié)調(diào)是微不足道的(因?yàn)樗行枰慕M件都是共處的)，而現(xiàn)在你必須協(xié)調(diào)repo之間的信息流。例如：當(dāng)構(gòu)建一個(gè)新的Docker鏡像時(shí)，這可能需要觸發(fā)集中式平臺(tái)repo中的部署，同時(shí)將新的鏡像名稱(chēng)作為觸發(fā)的一部分傳遞過(guò)來(lái)。

同樣，這些也不是無(wú)法解決的問(wèn)題，但在構(gòu)建GitOps流水線的早期，這些挑戰(zhàn)更容易實(shí)現(xiàn)。后來(lái)，當(dāng)步驟、政策和流程更加成熟時(shí)，再做出改變就需要付出更多的時(shí)間代價(jià)。

分布式vs集中式

你的業(yè)務(wù)正在增長(zhǎng)，你正在構(gòu)建越來(lái)越多的應(yīng)用程序和服務(wù)。越來(lái)越明顯的是，在如何構(gòu)建和部署應(yīng)用程序方面，你需要某種結(jié)構(gòu)上的一致性。中央平臺(tái)團(tuán)隊(duì)需要嘗試執(zhí)行這些標(biāo)準(zhǔn)。但是你可能會(huì)遭到開(kāi)發(fā)團(tuán)隊(duì)的反對(duì)，他們認(rèn)為與在DevOps和GitOps出現(xiàn)之前，在集中式IT中他們被賦予了更多的自治和控制權(quán)。

如果上述情況您覺(jué)得似曾相識(shí)，那可能是因?yàn)镚itOps和應(yīng)用架構(gòu)領(lǐng)域的單體與微服務(wù)爭(zhēng)論之間有些類(lèi)似。就像你在這些爭(zhēng)論中看到的那樣，隨著系統(tǒng)的成熟，規(guī)模和范圍的擴(kuò)大，分布式和集中式IT之間的緊張關(guān)系會(huì)越來(lái)越頻繁地出現(xiàn)。

從某種層面上來(lái)說(shuō)，你的GitOps流程就像其他分布式系統(tǒng)一樣，如果你設(shè)計(jì)得不好，其中一個(gè)部分出現(xiàn)問(wèn)題可能會(huì)產(chǎn)生難以預(yù)料的問(wèn)題。

環(huán)　境

在你決定分離repo的同時(shí)，你意識(shí)到你需要一種一致的方式來(lái)管理不同的部署環(huán)境。而直接上線已經(jīng)行不通了，因?yàn)榇藭r(shí)需要QA團(tuán)隊(duì)，在上線之前測(cè)試更改。

現(xiàn)在你需要為你的應(yīng)用鏡像在測(cè)試和QA環(huán)境中指定不同的Docker標(biāo)簽，你可能還希望在不同的環(huán)境中啟用不同大小的實(shí)例大小或副本功能。你如何在源碼中管理這些不同環(huán)境的配置?一個(gè)比較直接的方法是為每個(gè)環(huán)境建立一個(gè)單獨(dú)的Git倉(cāng)庫(kù)(如：super-app-dev，super-app-qa，super-app-live)。

分離repo有 “涇渭分明” 的好處，就像我們?cè)谏厦鎰澐諸erraform代碼時(shí)看到的那樣。然而，很少有人最終會(huì)喜歡這種解決方案，因?yàn)榇蠖鄶?shù)團(tuán)隊(duì)不具備Git知識(shí)和相關(guān)專(zhuān)業(yè)水平，進(jìn)而在不同的repo之間移植更改。更為復(fù)雜的是，repo之間必然會(huì)存在很多重復(fù)的代碼，而且隨著時(shí)間的推移，也可能會(huì)出現(xiàn)很多漂移(drift)。

如果你想把事情保持在一個(gè)單一的repo中，你至少有三種選擇：

• 每個(gè)環(huán)境都有一個(gè)目錄
• 每個(gè)環(huán)境都有一個(gè)分支
• 每個(gè)環(huán)境有一個(gè)標(biāo)簽

同步步驟選擇

如果你嚴(yán)重依賴(lài)YAML生成工具或模板，您可以考慮另一種方式。例如，Kustomize強(qiáng)烈鼓勵(lì)基于目錄的環(huán)境分離。如果您使用的是原始YAML，那么分支或標(biāo)記的方法會(huì)更適合您。

運(yùn)行時(shí)環(huán)境顆粒度

然而，在您的運(yùn)行時(shí)環(huán)境中，可以選擇您想要什么級(jí)別的分離。在集群層面，如果您使用的是Kubernetes，你可以在以下幾種情況下選擇：

• 一個(gè)集群管理所有
• 每個(gè)環(huán)境一個(gè)集群
• 每個(gè)團(tuán)隊(duì)一個(gè)集群

在極端情況下，你可以把所有的環(huán)境放到一個(gè)集群中。不過(guò)通常情況下，在大多數(shù)組織中至少有一個(gè)單獨(dú)的集群用于生產(chǎn)。

一旦你想好了你的集群策略，在命名空間層面，你仍然可以選擇：

• 每個(gè)環(huán)境都有一個(gè)命名空間
• 每個(gè)應(yīng)用程序/服務(wù)擁有一個(gè)命名空間
• 每個(gè)工程師擁有一個(gè)命名空間
• 每個(gè)構(gòu)建都有一個(gè)命名空間

平臺(tái)團(tuán)隊(duì)通常從 “dev”、“test”、“prod” 的命名空間設(shè)置開(kāi)始，然后才意識(shí)到他們想要更精細(xì)地分化團(tuán)隊(duì)的工作。

你也可以混合和匹配這些選項(xiàng)——例如，為每個(gè)工程師提供"desk testing "命名空間，以及每個(gè)團(tuán)隊(duì)的命名空間。

總 結(jié)

我們?cè)谶@里只是對(duì)成熟的GitOps流程所需的決策領(lǐng)域做了一些簡(jiǎn)單的介紹。如果您的企業(yè)真的成長(zhǎng)為那家跨國(guó)企業(yè)，你也可以考慮RBAC/IAM等要求。

通常情況下，推出GitOps會(huì)讓人覺(jué)得只是一種投資，可能最終沒(méi)有太多令人滿意的產(chǎn)出。但是在GitOps之前，團(tuán)隊(duì)常常會(huì)經(jīng)歷混亂和延遲，因?yàn)闆](méi)有人能夠確定任何東西應(yīng)該是什么狀態(tài)。這些都會(huì)導(dǎo)致二次成本，因?yàn)閷徲?jì)人員會(huì)進(jìn)行抽查，而因意外和未記錄的更改而導(dǎo)致的中斷則占據(jù)了員工大量的注意力，這是一個(gè)很高的成本。

然而，隨著你的GitOps流程的愈發(fā)成熟，好處倍增，該流程會(huì)解決許多之前存在的問(wèn)題。但更多的時(shí)候，你面臨的壓力是要更快地展現(xiàn)出GitOps流程的優(yōu)勢(shì)。

目前GitOps最大的挑戰(zhàn)是，沒(méi)有既定的模式或是最佳實(shí)踐來(lái)指導(dǎo)你的選擇。GitOps顧問(wèn)，通常也只是引導(dǎo)團(tuán)隊(duì)找到最適合他們的解決方案，并根據(jù)經(jīng)驗(yàn)將團(tuán)隊(duì)往某些方向引導(dǎo)。

但我觀察到的情況是，早期因?yàn)榭雌饋?lái) “太復(fù)雜”而被放棄的選擇，往往后來(lái)都會(huì)為此后悔。這并不意味著你應(yīng)該直接跳到為每個(gè)構(gòu)建創(chuàng)建一個(gè)命名空間，每個(gè)團(tuán)隊(duì)擁有一個(gè)Kubernetes集群的程度，原因有二：

• 每當(dāng)你給GitOps架構(gòu)增加復(fù)雜性時(shí)，你最終都會(huì)增加交付一個(gè)可行的GitOps解決方案的成本和時(shí)間
• 你可能真的永遠(yuǎn)都不需要這種設(shè)置

在我們接受這個(gè)領(lǐng)域的可行標(biāo)準(zhǔn)之前，正確的 GitOps 架構(gòu)永遠(yuǎn)是一門(mén)藝術(shù)，而不是科學(xué)。