對齊部署鏡像和描述符是很困難的，但是某些策略可以使整個過程更高效。

在軟件架構(gòu)中，當(dāng)兩個組件之間有某些概念性或技術(shù)上的差異時會出現(xiàn) 阻抗失配impedance mismatch。這個術(shù)語其實是從電子工程中借用的，表示電路中輸入和輸出的電子阻抗必須要匹配。

在軟件開發(fā)中，存儲在鏡像倉庫中的鏡像與存儲在源碼控制管理系統(tǒng)(LCTT 譯注：SCM，Source Code Management)中它的部署描述符deployment descriptor之間存在阻抗失配。你如何確定存儲在 SCM 中的部署描述符表示的是正確的鏡像?兩個倉庫追蹤數(shù)據(jù)的方式并不一致，因此將一個鏡像(在鏡像倉庫中獨(dú)立存儲的不可修改的二進(jìn)制)和它的部署描述符(Git 中以文本文件形式存儲的一系列修改記錄)相匹配并不那么直觀。

注意：本文假定讀者已經(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 與鏡像倉庫

為了更好地理解阻抗失配在什么場景下會成為問題，請考慮任意項目中的軟件開發(fā)生命周期環(huán)境(SDLC)，如開發(fā)、測試或發(fā)布環(huán)境。

測試環(huán)境不會有阻抗失配?，F(xiàn)在使用 CI/CD 的最佳實踐中開發(fā)分支的最新提交都會對應(yīng)開發(fā)環(huán)境中的最新部署。因此，一個典型的、成功的 CI/CD 開發(fā)流程如下：

• 向 SCM 的開發(fā)分支提交新的修改
• 新提交觸發(fā)一次鏡像構(gòu)建
• 新生成的鏡像被推送到鏡像倉庫，標(biāo)記為開發(fā)中
• 鏡像被部署到容器編排系統(tǒng)(COP)中的開發(fā)環(huán)境，該鏡像的部署描述符也更新為從 SCM 拉取的最新描述符。

換句話說，開發(fā)環(huán)境中最新的鏡像永遠(yuǎn)與最新的部署描述符匹配。回滾到前一個構(gòu)建的版本也不是問題，因為 SCM 也會跟著回滾。

最終，隨著開發(fā)流程繼續(xù)推進(jìn)，需要進(jìn)行更多正式的測試，因此某個鏡像 —— 鏡像對應(yīng)著 SCM 中的某次提交 —— 被推到測試環(huán)境。如果是一次成功的構(gòu)建，那么不會有大問題，因為從開發(fā)環(huán)境推過來的鏡像應(yīng)該會與開發(fā)分支的最新提交相對應(yīng)。

• 開發(fā)環(huán)境的最新部署被允許入庫，觸發(fā)入庫過程
• 最新部署的鏡像被標(biāo)記為測試中
• 鏡像在測試環(huán)境中被拉取和部署，(該鏡像)對應(yīng)從 SCM 拉取的最新部署描述符

到目前為止,一切都沒有問題，對嗎?如果出現(xiàn)下面的場景，會有什么問題?

• 場景 A：鏡像被推到下游環(huán)境，如用戶驗收測試user acceptance testing(UAT)，或者是生產(chǎn)環(huán)境。
• 場景 B：測試環(huán)境中發(fā)現(xiàn)了一個破壞性的 bug，鏡像需要回滾到某個確定正常的版本。

在任一場景中，開發(fā)過程并沒有停止，即開發(fā)分支上游有了一次或多次新的提交，而這意味著最新的部署描述符已經(jīng)發(fā)生了變化，最新的鏡像與之前部署在測試環(huán)境中的鏡像不一致。對部署描述符的修改可能會也可能不會對之前版本的鏡像起作用，但是它們一定是不可信任的。如果它們有了變化，那么它們就一定與目前為止你測試過的想要部署的鏡像的部署描述符不一致。

問題的關(guān)鍵是：如果部署的鏡像不是鏡像庫中的最新版本，你怎么確定與部署的鏡像相對應(yīng)的是 SCM 中的哪個部署描述符? 一言以蔽之，無法確定。兩個庫直接有阻抗失配。如果要詳細(xì)闡述下，那么是有方法可以解決的，但是你需要做很多工作，這部分內(nèi)容就是文章接下來的主題了。請注意，下面的方案并不是解決問題的唯一辦法，但是已經(jīng)投入到生產(chǎn)環(huán)境并已經(jīng)對很多項目起了作用，而且已經(jīng)被構(gòu)建并部署到生產(chǎn)環(huán)境中運(yùn)行了超過一年。

二進(jìn)制與部署描述符

源碼通常被構(gòu)建成一個 Docker 鏡像或符合 OCI 標(biāo)準(zhǔn)的鏡像，該鏡像通常被部署到一個容器編排平臺(COP)上，如 Kubernetes。部署到 COP 需要部署描述符來定義鏡像被如何部署以及作為容器運(yùn)行，如 Kubernetes 部署 或 CronJobs。這是因為在鏡像和它的部署描述符之間有本質(zhì)差異，在這里可以看到阻抗失配。在這次討論中，我們認(rèn)為鏡像是存儲在鏡像倉庫中不可修改的二進(jìn)制。對源碼的任何修改都不會修改鏡像，而是用另一個新的鏡像去替換它。

相比之下，部署描述符是文本文件，因而可以被認(rèn)為是源碼且可修改。如果遵循最佳實踐，那么部署描述符是被存儲在 SCM，所有修改都會提交，而這很容易回溯。

解決阻抗失配

建議的解決方案的第一部分，就是提供一個能匹配鏡像倉庫中的鏡像與對保存部署描述符的 SCM 做的代碼提交的方法。最直接的解決方案是用源提交的哈希值標(biāo)記鏡像。這個方法可以區(qū)分不同版本的鏡像、容易分辨，并且提供足夠的信息來查找正確的部署描述符，以便鏡像更好地部署到 COP。

再回顧下上面的場景：

• 場景 A 鏡像被推到下游環(huán)境： 當(dāng)鏡像被從測試環(huán)境推到 UAT 環(huán)境時，我們可以從鏡像的標(biāo)簽中知道應(yīng)該從 SCM 的哪一次源碼提交拉取部署描述符。
• 場景 B 當(dāng)一個鏡像需要在某一環(huán)節(jié)中回滾：無論我們選擇回滾到那個鏡像版本，我們都可以知道從 SCM 的哪一次源碼提交拉取正確的部署描述符。

在每一種情景中，無論在某個鏡像被部署到測試環(huán)境后開發(fā)分支有多少次提交和構(gòu)建，對于每一次升級的鏡像，我們都可以找到它當(dāng)初部署時對應(yīng)的部署描述符。

然而，這并不是阻抗失配的完整解決方案。再考慮兩個場景：

• 場景 C 在負(fù)載測試環(huán)境中，會嘗試對不同的部署描述符進(jìn)行多次部署，以此來驗證某一次構(gòu)建的表現(xiàn)。
• 場景 D 一個鏡像被推送到下游環(huán)境，在該環(huán)境中部署描述符有一個錯誤。

在上面的所有場景中，我們都需要修改部署描述符，但是目前為止我們只有一個源碼提交哈希。請記住，最佳實踐要求我們所有對源碼的修改都要先提交到 SCM。某次提交的哈希本身是無法修改的，因此我們需要一個比僅僅追蹤原來的源碼提交哈希更好地解決方案。

解決方案是基于原來的源碼提交哈希新建一個分支。我們把這個分支稱為部署分支。每當(dāng)一個鏡像被推到下游測試或發(fā)布環(huán)境時，你應(yīng)該基于前一個 SDLC 環(huán)境的部署分支的最新提交創(chuàng)建一個新的部署分支。

這樣同一個鏡像可以重復(fù)多次部署到不同的 SDLC 環(huán)境，并在后面每個環(huán)境中可以感知前面發(fā)現(xiàn)的改動或?qū)︾R像做的修改。

注意： 在某個環(huán)境中做的修改是如何影響下一個環(huán)境的，是用可以共享數(shù)據(jù)的工具(如 Helm Charts)還是手動剪切、粘貼到其他目錄，都不在本文討論的范圍內(nèi)。

因此，當(dāng)一個鏡像被從一個 SDLC 環(huán)境中推到下一環(huán)境時：

創(chuàng)建一個部署分支

• 如果鏡像是從開發(fā)環(huán)境中推過來的，那么部署分支就基于構(gòu)建這個鏡像的源碼提交哈希創(chuàng)建
• 否則，部署分支基于當(dāng)前部署分支的最新提交創(chuàng)建

鏡像被部署到下一個 SDLC 環(huán)境，使用的部署描述符是該環(huán)境中新創(chuàng)建的部署分支的部署描述符

圖 1：部署分支樹

• 部署分支
• 下游環(huán)境的第一個部署分支，只有一次提交
• 下游環(huán)境的第二個部署分支，只有一次提交

有了部署分支這個解決方案，再回顧下上面的場景 C 和場景 D：

• 場景 C 修改已經(jīng)部署到下游 SDLC 環(huán)境中的鏡像的部署描述符
• 場景 D 修復(fù)某個 SDLC 環(huán)境中部署描述符的錯誤

兩個場景中，工作流如下：

• 把對部署描述符做的修改提交到 SLDC 環(huán)境和鏡像對應(yīng)的部署分支
• 通過部署分支最新提交對應(yīng)的部署描述符把鏡像重新部署到 SLDC 環(huán)境

這樣，部署分支徹底解決了(存儲著代表一次獨(dú)一無二的構(gòu)建的單一的、不可修改的鏡像的)鏡像倉庫與(存儲著對應(yīng)一個或多個 SDLC 環(huán)境的可修改的部署描述符的)SCM 倉庫之間的阻抗失配。

實踐中的思考

這看起來像是行得通的解決方案，但同時它也為開發(fā)者和運(yùn)維人員帶來了新的實踐中的問題，比如：

A. 為了更好地管理部署分支，部署描述符作為資源應(yīng)該保存在哪里，是否要與構(gòu)建鏡像的源碼保存在同一個 SCM 倉庫?

到目前為止，我們都在避免談?wù)搼?yīng)該把部署描述符放在哪個倉庫里。在還沒有太多細(xì)節(jié)需要處理時，我們推薦把所有 SDLC 環(huán)境的部署描述符與鏡像源碼放在同一個 SCM 倉庫。當(dāng)部署分支創(chuàng)建后，鏡像的源碼可以作為方便找到部署的容器中運(yùn)行的鏡像的引用來使用。

上面提到過，可以通過鏡像的標(biāo)簽來關(guān)聯(lián)鏡像與原始的源碼提交。在一個單獨(dú)的倉庫中查找某次提交的源碼的引用，會給開發(fā)者帶來更大的困難(即便借助工具)，這就是沒有必要把所有資源都分開存儲的原因。

B. 應(yīng)該在部署分支上修改構(gòu)建鏡像的源碼嗎?

簡答：不應(yīng)該。

詳細(xì)闡述：不應(yīng)該，因為永遠(yuǎn)不要在部署分支上構(gòu)建鏡像，它們是在開發(fā)分支上構(gòu)建的。修改部署分支上定義一個鏡像的源碼會破壞被部署的鏡像的構(gòu)建記錄，而且這些修改并不會對鏡像的功能生效。在對比兩個部署分支的版本時這也會成為問題。這可能會導(dǎo)致兩個版本的功能差異有錯誤的測試結(jié)果(這是使用部署分支的一個很小的額外好處)。

C. 為什么使用鏡像 標(biāo)簽tag?標(biāo)記label 不可以嗎?

通過 標(biāo)簽tag 可以在倉庫中很容易地查找鏡像，可讀性也很好。在一組鏡像中讀取和查找 標(biāo)記label 的值需要拉取所有鏡像的清單文件manifest，而這會增加復(fù)雜度、降低性能。而且，考慮到歷史記錄的追蹤和不同版本的查找，對不同版本的鏡像添加 標(biāo)簽tag 也很有必要，因此使用源碼提交哈希是保證唯一性，以及保存能即時生效的有用信息的最簡單的解決方案。

D. 創(chuàng)建部署分支的最佳實踐是怎樣的?

DevOps 最重要的三個原則：自動化、自動化、自動化。

依賴資源來持續(xù)地強(qiáng)迫遵循最佳實踐，充其量只是碰運(yùn)氣，因此在實現(xiàn)鏡像的升級、回滾等 CI/CD 流水線時，把自動化部署分支寫到腳本里。

E. 對部署分支的命名規(guī)范有建議嗎?

<部署分支標(biāo)識>-<環(huán)境>-<源碼提交哈希>

• 部署分支標(biāo)識： 所有部署分支范圍內(nèi)唯一的字符串;如 “deployment” 或 “deploy”
• 環(huán)境： 部署分支適用的 SDLC 環(huán)境;如 “qa”(測試環(huán)境)、 “stg”(預(yù)生產(chǎn)環(huán)境)、 或 “prod”(生產(chǎn)環(huán)境)
• 源碼提交哈希： 源碼提交哈希中包含原來構(gòu)建被部署的鏡像的源碼，開發(fā)者可以通過它很容易地查找到創(chuàng)建鏡像的原始提交，同時也能保證分支名唯一。

例如， deployment-qa-asdf78s 表示推到 QA 環(huán)境的部署分支， deployment-stg-asdf78s 表示推到 STG 環(huán)境的部署分支。

F. 你怎么識別環(huán)境中運(yùn)行的哪個鏡像版本?

我們的建議是把最新的部署分支提交哈希和源碼提交哈希添加到 標(biāo)記 中。開發(fā)者和運(yùn)維人員可以通過這兩個獨(dú)一無二的標(biāo)識符查找到部署的所有東西及其來源。在諸如執(zhí)行回滾或前滾操作時，使用那些不同版本的部署的選擇器也能清理資源碎片。

G. 什么時候應(yīng)該把部署分支的修改合并回開發(fā)分支?

這完全取決于開發(fā)團(tuán)隊。

如果你修改的目的是為了做負(fù)載測試，只是想驗證什么情況會讓程序崩潰，那么這些修改不應(yīng)該被合并回開發(fā)分支。另一方面，如果你發(fā)現(xiàn)和修復(fù)了一個錯誤，或者對下游環(huán)境的部署做了調(diào)整，那么就應(yīng)該把部署分支的修改合并回開發(fā)分支。

H. 有現(xiàn)成的部署分支示例讓我們試水嗎?

el-CICD 已經(jīng)在生產(chǎn)上使用這個策略持續(xù)一年半應(yīng)用到超過一百個項目了，覆蓋所有的 SDLC 環(huán)境，包括管理生產(chǎn)環(huán)境的部署。如果你可以訪問 OKD、Red Hat OpenShift lab cluster 或 Red Hat CodeReady Containers，你可以下載el-CICD 的最新版本，參照 教程 來學(xué)習(xí)部署分支是何時以怎樣的方式創(chuàng)建和使用的。

結(jié)語

通過實踐上面的例子可以幫助你更好的理解開發(fā)過程中阻抗失配相關(guān)的問題。對齊鏡像和部署描述符是成功管理部署的關(guān)鍵部分。