解決 CI/CD 中的倉(cāng)庫(kù)阻抗失配
對(duì)齊部署鏡像和描述符是很困難的，但是某些策略可以使整個(gè)過(guò)程更高效。
在軟件架構(gòu)中，當(dāng)兩個(gè)組件之間有某些概念性或技術(shù)上的差異時(shí)會(huì)出現(xiàn) 阻抗失配impedance mismatch。這個(gè)術(shù)語(yǔ)其實(shí)是從電子工程中借用的，表示電路中輸入和輸出的電子阻抗必須要匹配。
在軟件開發(fā)中，存儲(chǔ)在鏡像倉(cāng)庫(kù)中的鏡像與存儲(chǔ)在源碼控制管理系統(tǒng)(LCTT 譯注：SCM，Source Code Management)中它的部署描述符deployment descriptor之間存在阻抗失配。你如何確定存儲(chǔ)在 SCM 中的部署描述符表示的是正確的鏡像?兩個(gè)倉(cāng)庫(kù)追蹤數(shù)據(jù)的方式并不一致，因此將一個(gè)鏡像(在鏡像倉(cāng)庫(kù)中獨(dú)立存儲(chǔ)的不可修改的二進(jìn)制)和它的部署描述符(Git 中以文本文件形式存儲(chǔ)的一系列修改記錄)相匹配并不那么直觀。
注意：本文假定讀者已經(jīng)熟悉以下概念：
- 源碼控制管理Source Control Management(SCM)系統(tǒng)和分支
- Docker 或符合 OCI 標(biāo)準(zhǔn)的鏡像和容器
- 容器編排系統(tǒng)Container Orchestration Platforms(COP)，如 Kubernetes
- 持續(xù)集成/持續(xù)交付Continuous Integration/Continuous Delivery(CI/CD)
- 軟件開發(fā)生命周期Software development lifecycle(SDLC)環(huán)境
阻抗失配：SCM 與鏡像倉(cāng)庫(kù)
為了更好地理解阻抗失配在什么場(chǎng)景下會(huì)成為問(wèn)題，請(qǐng)考慮任意項(xiàng)目中的軟件開發(fā)生命周期環(huán)境(SDLC)，如開發(fā)、測(cè)試或發(fā)布環(huán)境。
測(cè)試環(huán)境不會(huì)有阻抗失配?，F(xiàn)在使用 CI/CD 的最佳實(shí)踐中開發(fā)分支的最新提交都會(huì)對(duì)應(yīng)開發(fā)環(huán)境中的最新部署。因此，一個(gè)典型的、成功的 CI/CD 開發(fā)流程如下：
- 向 SCM 的開發(fā)分支提交新的修改
- 新提交觸發(fā)一次鏡像構(gòu)建
- 新生成的鏡像被推送到鏡像倉(cāng)庫(kù)，標(biāo)記為開發(fā)中
- 鏡像被部署到容器編排系統(tǒng)(COP)中的開發(fā)環(huán)境，該鏡像的部署描述符也更新為從 SCM 拉取的最新描述符。
換句話說(shuō)，開發(fā)環(huán)境中最新的鏡像永遠(yuǎn)與最新的部署描述符匹配。回滾到前一個(gè)構(gòu)建的版本也不是問(wèn)題，因?yàn)?SCM 也會(huì)跟著回滾。
最終，隨著開發(fā)流程繼續(xù)推進(jìn)，需要進(jìn)行更多正式的測(cè)試，因此某個(gè)鏡像 —— 鏡像對(duì)應(yīng)著 SCM 中的某次提交 —— 被推到測(cè)試環(huán)境。如果是一次成功的構(gòu)建，那么不會(huì)有大問(wèn)題，因?yàn)閺拈_發(fā)環(huán)境推過(guò)來(lái)的鏡像應(yīng)該會(huì)與開發(fā)分支的最新提交相對(duì)應(yīng)。
- 開發(fā)環(huán)境的最新部署被允許入庫(kù)，觸發(fā)入庫(kù)過(guò)程
- 最新部署的鏡像被標(biāo)記為測(cè)試中
- 鏡像在測(cè)試環(huán)境中被拉取和部署，(該鏡像)對(duì)應(yīng)從 SCM 拉取的最新部署描述符
到目前為止,一切都沒(méi)有問(wèn)題，對(duì)嗎?如果出現(xiàn)下面的場(chǎng)景，會(huì)有什么問(wèn)題?
- 場(chǎng)景 A：鏡像被推到下游環(huán)境，如用戶驗(yàn)收測(cè)試user acceptance testing(UAT)，或者是生產(chǎn)環(huán)境。
- 場(chǎng)景 B：測(cè)試環(huán)境中發(fā)現(xiàn)了一個(gè)破壞性的 bug，鏡像需要回滾到某個(gè)確定正常的版本。
在任一場(chǎng)景中，開發(fā)過(guò)程并沒(méi)有停止，即開發(fā)分支上游有了一次或多次新的提交，而這意味著最新的部署描述符已經(jīng)發(fā)生了變化，最新的鏡像與之前部署在測(cè)試環(huán)境中的鏡像不一致。對(duì)部署描述符的修改可能會(huì)也可能不會(huì)對(duì)之前版本的鏡像起作用，但是它們一定是不可信任的。如果它們有了變化，那么它們就一定與目前為止你測(cè)試過(guò)的想要部署的鏡像的部署描述符不一致。
問(wèn)題的關(guān)鍵是：如果部署的鏡像不是鏡像庫(kù)中的最新版本，你怎么確定與部署的鏡像相對(duì)應(yīng)的是 SCM 中的哪個(gè)部署描述符? 一言以蔽之，無(wú)法確定。兩個(gè)庫(kù)直接有阻抗失配。如果要詳細(xì)闡述下，那么是有方法可以解決的，但是你需要做很多工作，這部分內(nèi)容就是文章接下來(lái)的主題了。請(qǐng)注意，下面的方案并不是解決問(wèn)題的唯一辦法，但是已經(jīng)投入到生產(chǎn)環(huán)境并已經(jīng)對(duì)很多項(xiàng)目起了作用，而且已經(jīng)被構(gòu)建并部署到生產(chǎn)環(huán)境中運(yùn)行了超過(guò)一年。
二進(jìn)制與部署描述符
源碼通常被構(gòu)建成一個(gè) Docker 鏡像或符合 OCI 標(biāo)準(zhǔn)的鏡像，該鏡像通常被部署到一個(gè)容器編排平臺(tái)(COP)上，如 Kubernetes。部署到 COP 需要部署描述符來(lái)定義鏡像被如何部署以及作為容器運(yùn)行，如 Kubernetes 部署 或 CronJobs。這是因?yàn)樵阽R像和它的部署描述符之間有本質(zhì)差異，在這里可以看到阻抗失配。在這次討論中，我們認(rèn)為鏡像是存儲(chǔ)在鏡像倉(cāng)庫(kù)中不可修改的二進(jìn)制。對(duì)源碼的任何修改都不會(huì)修改鏡像，而是用另一個(gè)新的鏡像去替換它。
相比之下，部署描述符是文本文件，因而可以被認(rèn)為是源碼且可修改。如果遵循最佳實(shí)踐，那么部署描述符是被存儲(chǔ)在 SCM，所有修改都會(huì)提交，而這很容易回溯。
解決阻抗失配
建議的解決方案的第一部分，就是提供一個(gè)能匹配鏡像倉(cāng)庫(kù)中的鏡像與對(duì)保存部署描述符的 SCM 做的代碼提交的方法。最直接的解決方案是用源提交的哈希值標(biāo)記鏡像。這個(gè)方法可以區(qū)分不同版本的鏡像、容易分辨，并且提供足夠的信息來(lái)查找正確的部署描述符，以便鏡像更好地部署到 COP。
再回顧下上面的場(chǎng)景：
- 場(chǎng)景 A 鏡像被推到下游環(huán)境： 當(dāng)鏡像被從測(cè)試環(huán)境推到 UAT 環(huán)境時(shí)，我們可以從鏡像的標(biāo)簽中知道應(yīng)該從 SCM 的哪一次源碼提交拉取部署描述符。
- 場(chǎng)景 B 當(dāng)一個(gè)鏡像需要在某一環(huán)節(jié)中回滾：無(wú)論我們選擇回滾到那個(gè)鏡像版本，我們都可以知道從 SCM 的哪一次源碼提交拉取正確的部署描述符。
在每一種情景中，無(wú)論在某個(gè)鏡像被部署到測(cè)試環(huán)境后開發(fā)分支有多少次提交和構(gòu)建，對(duì)于每一次升級(jí)的鏡像，我們都可以找到它當(dāng)初部署時(shí)對(duì)應(yīng)的部署描述符。
然而，這并不是阻抗失配的完整解決方案。再考慮兩個(gè)場(chǎng)景：
- 場(chǎng)景 C 在負(fù)載測(cè)試環(huán)境中，會(huì)嘗試對(duì)不同的部署描述符進(jìn)行多次部署，以此來(lái)驗(yàn)證某一次構(gòu)建的表現(xiàn)。
- 場(chǎng)景 D 一個(gè)鏡像被推送到下游環(huán)境，在該環(huán)境中部署描述符有一個(gè)錯(cuò)誤。
在上面的所有場(chǎng)景中，我們都需要修改部署描述符，但是目前為止我們只有一個(gè)源碼提交哈希。請(qǐng)記住，最佳實(shí)踐要求我們所有對(duì)源碼的修改都要先提交到 SCM。某次提交的哈希本身是無(wú)法修改的，因此我們需要一個(gè)比僅僅追蹤原來(lái)的源碼提交哈希更好地解決方案。
解決方案是基于原來(lái)的源碼提交哈希新建一個(gè)分支。我們把這個(gè)分支稱為部署分支。每當(dāng)一個(gè)鏡像被推到下游測(cè)試或發(fā)布環(huán)境時(shí)，你應(yīng)該基于前一個(gè) SDLC 環(huán)境的部署分支的最新提交創(chuàng)建一個(gè)新的部署分支。
這樣同一個(gè)鏡像可以重復(fù)多次部署到不同的 SDLC 環(huán)境，并在后面每個(gè)環(huán)境中可以感知前面發(fā)現(xiàn)的改動(dòng)或?qū)︾R像做的修改。
注意： 在某個(gè)環(huán)境中做的修改是如何影響下一個(gè)環(huán)境的，是用可以共享數(shù)據(jù)的工具(如 Helm Charts)還是手動(dòng)剪切、粘貼到其他目錄，都不在本文討論的范圍內(nèi)。
因此，當(dāng)一個(gè)鏡像被從一個(gè) SDLC 環(huán)境中推到下一環(huán)境時(shí)：
創(chuàng)建一個(gè)部署分支
- 如果鏡像是從開發(fā)環(huán)境中推過(guò)來(lái)的，那么部署分支就基于構(gòu)建這個(gè)鏡像的源碼提交哈希創(chuàng)建
- 否則，部署分支基于當(dāng)前部署分支的最新提交創(chuàng)建
鏡像被部署到下一個(gè) SDLC 環(huán)境，使用的部署描述符是該環(huán)境中新創(chuàng)建的部署分支的部署描述符
圖 1：部署分支樹
- 部署分支
- 下游環(huán)境的第一個(gè)部署分支，只有一次提交
- 下游環(huán)境的第二個(gè)部署分支，只有一次提交
有了部署分支這個(gè)解決方案，再回顧下上面的場(chǎng)景 C 和場(chǎng)景 D：
- 場(chǎng)景 C 修改已經(jīng)部署到下游 SDLC 環(huán)境中的鏡像的部署描述符
- 場(chǎng)景 D 修復(fù)某個(gè) SDLC 環(huán)境中部署描述符的錯(cuò)誤
兩個(gè)場(chǎng)景中，工作流如下：
- 把對(duì)部署描述符做的修改提交到 SLDC 環(huán)境和鏡像對(duì)應(yīng)的部署分支
- 通過(guò)部署分支最新提交對(duì)應(yīng)的部署描述符把鏡像重新部署到 SLDC 環(huán)境
這樣，部署分支徹底解決了(存儲(chǔ)著代表一次獨(dú)一無(wú)二的構(gòu)建的單一的、不可修改的鏡像的)鏡像倉(cāng)庫(kù)與(存儲(chǔ)著對(duì)應(yīng)一個(gè)或多個(gè) SDLC 環(huán)境的可修改的部署描述符的)SCM 倉(cāng)庫(kù)之間的阻抗失配。
實(shí)踐中的思考
這看起來(lái)像是行得通的解決方案，但同時(shí)它也為開發(fā)者和運(yùn)維人員帶來(lái)了新的實(shí)踐中的問(wèn)題，比如：
A. 為了更好地管理部署分支，部署描述符作為資源應(yīng)該保存在哪里，是否要與構(gòu)建鏡像的源碼保存在同一個(gè) SCM 倉(cāng)庫(kù)?
到目前為止，我們都在避免談?wù)搼?yīng)該把部署描述符放在哪個(gè)倉(cāng)庫(kù)里。在還沒(méi)有太多細(xì)節(jié)需要處理時(shí)，我們推薦把所有 SDLC 環(huán)境的部署描述符與鏡像源碼放在同一個(gè) SCM 倉(cāng)庫(kù)。當(dāng)部署分支創(chuàng)建后，鏡像的源碼可以作為方便找到部署的容器中運(yùn)行的鏡像的引用來(lái)使用。
上面提到過(guò)，可以通過(guò)鏡像的標(biāo)簽來(lái)關(guān)聯(lián)鏡像與原始的源碼提交。在一個(gè)單獨(dú)的倉(cāng)庫(kù)中查找某次提交的源碼的引用，會(huì)給開發(fā)者帶來(lái)更大的困難(即便借助工具)，這就是沒(méi)有必要把所有資源都分開存儲(chǔ)的原因。
B. 應(yīng)該在部署分支上修改構(gòu)建鏡像的源碼嗎?
簡(jiǎn)答：不應(yīng)該。
詳細(xì)闡述：不應(yīng)該，因?yàn)橛肋h(yuǎn)不要在部署分支上構(gòu)建鏡像，它們是在開發(fā)分支上構(gòu)建的。修改部署分支上定義一個(gè)鏡像的源碼會(huì)破壞被部署的鏡像的構(gòu)建記錄，而且這些修改并不會(huì)對(duì)鏡像的功能生效。在對(duì)比兩個(gè)部署分支的版本時(shí)這也會(huì)成為問(wèn)題。這可能會(huì)導(dǎo)致兩個(gè)版本的功能差異有錯(cuò)誤的測(cè)試結(jié)果(這是使用部署分支的一個(gè)很小的額外好處)。
C. 為什么使用鏡像 標(biāo)簽tag?標(biāo)記label 不可以嗎?
通過(guò) 標(biāo)簽tag 可以在倉(cāng)庫(kù)中很容易地查找鏡像，可讀性也很好。在一組鏡像中讀取和查找 標(biāo)記label 的值需要拉取所有鏡像的清單文件manifest，而這會(huì)增加復(fù)雜度、降低性能。而且，考慮到歷史記錄的追蹤和不同版本的查找，對(duì)不同版本的鏡像添加 標(biāo)簽tag 也很有必要，因此使用源碼提交哈希是保證唯一性，以及保存能即時(shí)生效的有用信息的最簡(jiǎn)單的解決方案。
D. 創(chuàng)建部署分支的最佳實(shí)踐是怎樣的?
DevOps 最重要的三個(gè)原則：自動(dòng)化、自動(dòng)化、自動(dòng)化。
依賴資源來(lái)持續(xù)地強(qiáng)迫遵循最佳實(shí)踐，充其量只是碰運(yùn)氣，因此在實(shí)現(xiàn)鏡像的升級(jí)、回滾等 CI/CD 流水線時(shí)，把自動(dòng)化部署分支寫到腳本里。
E. 對(duì)部署分支的命名規(guī)范有建議嗎?
<部署分支標(biāo)識(shí)>-<環(huán)境>-<源碼提交哈希>
- 部署分支標(biāo)識(shí)： 所有部署分支范圍內(nèi)唯一的字符串;如 “deployment” 或 “deploy”
- 環(huán)境： 部署分支適用的 SDLC 環(huán)境;如 “qa”(測(cè)試環(huán)境)、 “stg”(預(yù)生產(chǎn)環(huán)境)、 或 “prod”(生產(chǎn)環(huán)境)
- 源碼提交哈希： 源碼提交哈希中包含原來(lái)構(gòu)建被部署的鏡像的源碼，開發(fā)者可以通過(guò)它很容易地查找到創(chuàng)建鏡像的原始提交，同時(shí)也能保證分支名唯一。
例如， deployment-qa-asdf78s 表示推到 QA 環(huán)境的部署分支， deployment-stg-asdf78s 表示推到 STG 環(huán)境的部署分支。
F. 你怎么識(shí)別環(huán)境中運(yùn)行的哪個(gè)鏡像版本?
我們的建議是把最新的部署分支提交哈希和源碼提交哈希添加到 標(biāo)記 中。開發(fā)者和運(yùn)維人員可以通過(guò)這兩個(gè)獨(dú)一無(wú)二的標(biāo)識(shí)符查找到部署的所有東西及其來(lái)源。在諸如執(zhí)行回滾或前滾操作時(shí)，使用那些不同版本的部署的選擇器也能清理資源碎片。
G. 什么時(shí)候應(yīng)該把部署分支的修改合并回開發(fā)分支?
這完全取決于開發(fā)團(tuán)隊(duì)。
如果你修改的目的是為了做負(fù)載測(cè)試，只是想驗(yàn)證什么情況會(huì)讓程序崩潰，那么這些修改不應(yīng)該被合并回開發(fā)分支。另一方面，如果你發(fā)現(xiàn)和修復(fù)了一個(gè)錯(cuò)誤，或者對(duì)下游環(huán)境的部署做了調(diào)整，那么就應(yīng)該把部署分支的修改合并回開發(fā)分支。
H. 有現(xiàn)成的部署分支示例讓我們?cè)囁畣?
el-CICD 已經(jīng)在生產(chǎn)上使用這個(gè)策略持續(xù)一年半應(yīng)用到超過(guò)一百個(gè)項(xiàng)目了，覆蓋所有的 SDLC 環(huán)境，包括管理生產(chǎn)環(huán)境的部署。如果你可以訪問(wèn) OKD、Red Hat OpenShift lab cluster 或 Red Hat CodeReady Containers，你可以下載el-CICD 的最新版本，參照 教程 來(lái)學(xué)習(xí)部署分支是何時(shí)以怎樣的方式創(chuàng)建和使用的。
結(jié)語(yǔ)
通過(guò)實(shí)踐上面的例子可以幫助你更好的理解開發(fā)過(guò)程中阻抗失配相關(guān)的問(wèn)題。對(duì)齊鏡像和部署描述符是成功管理部署的關(guān)鍵部分。
