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

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

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

注意：本文假定讀者已經熟悉以下概念：

• 源碼控制管理Source Control Management(SCM)系統和分支
• Docker 或符合 OCI 標準的鏡像和容器
• 容器編排系統Container Orchestration Platforms(COP)，如 Kubernetes
• 持續集成/持續交付Continuous Integration/Continuous Delivery(CI/CD)
• 軟件開發生命周期Software development lifecycle(SDLC)環境

阻抗失配：SCM 與鏡像倉庫

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

測試環境不會有阻抗失配。現在使用 CI/CD 的最佳實踐中開發分支的最新提交都會對應開發環境中的最新部署。因此，一個典型的、成功的 CI/CD 開發流程如下：

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

換句話說，開發環境中最新的鏡像永遠與最新的部署描述符匹配?；貪L到前一個構建的版本也不是問題，因為 SCM 也會跟著回滾。

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

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

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

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

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

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

二進制與部署描述符

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

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

解決阻抗失配

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

再回顧下上面的場景：

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

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

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

• 場景 C 在負載測試環境中，會嘗試對不同的部署描述符進行多次部署，以此來驗證某一次構建的表現。
• 場景 D 一個鏡像被推送到下游環境，在該環境中部署描述符有一個錯誤。

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

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

這樣同一個鏡像可以重復多次部署到不同的 SDLC 環境，并在后面每個環境中可以感知前面發現的改動或對鏡像做的修改。

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

因此，當一個鏡像被從一個 SDLC 環境中推到下一環境時：

創建一個部署分支

• 如果鏡像是從開發環境中推過來的，那么部署分支就基于構建這個鏡像的源碼提交哈希創建
• 否則，部署分支基于當前部署分支的最新提交創建

鏡像被部署到下一個 SDLC 環境，使用的部署描述符是該環境中新創建的部署分支的部署描述符

圖 1：部署分支樹

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

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

• 場景 C 修改已經部署到下游 SDLC 環境中的鏡像的部署描述符
• 場景 D 修復某個 SDLC 環境中部署描述符的錯誤

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

• 把對部署描述符做的修改提交到 SLDC 環境和鏡像對應的部署分支
• 通過部署分支最新提交對應的部署描述符把鏡像重新部署到 SLDC 環境

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

實踐中的思考

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

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

到目前為止，我們都在避免談論應該把部署描述符放在哪個倉庫里。在還沒有太多細節需要處理時，我們推薦把所有 SDLC 環境的部署描述符與鏡像源碼放在同一個 SCM 倉庫。當部署分支創建后，鏡像的源碼可以作為方便找到部署的容器中運行的鏡像的引用來使用。

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

B. 應該在部署分支上修改構建鏡像的源碼嗎?

簡答：不應該。

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

C. 為什么使用鏡像 標簽tag?標記label 不可以嗎?

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

D. 創建部署分支的最佳實踐是怎樣的?

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

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

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

<部署分支標識>-<環境>-<源碼提交哈希>

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

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

F. 你怎么識別環境中運行的哪個鏡像版本?

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

G. 什么時候應該把部署分支的修改合并回開發分支?

這完全取決于開發團隊。

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

H. 有現成的部署分支示例讓我們試水嗎?

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

結語

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