1.Docker Image 分層存儲

為了最大化重用 Image，加快運行速度，減少內存和磁盤的占用，Docker container 運行時所構造的運行環境，實際上是由具有依賴關系的多個 Layer 組成的。如圖 1 所示，每一串數字 ID 就代表了一個 Docker Image Layer。當我們在 pull 一個 Docker Image 的時候我們會發現所有依賴的 Layer 文件將會被 download。

圖 1. Docker Image 分層示意圖

例如我們一個 Docker App Image 的運行環境是在基礎的 Docker Base Image 的基礎上，疊加了包含例如 anaconda等各種工具的 Image，再疊加包含模型文檔及其相關依賴庫的 Image，以及包含了最終應用的code包的 layer。這些 Image 由 AUFS 文件系統加載合并到統一路徑中，以只讀的方式存在，最后再疊加加載一層可寫的空白的 Layer 用作記錄對當前運行環境所作的修改。因此，當 Docker Image 每次由一個基礎 Image 創建后，新 Image 就自動增加了一層。如圖 2 所示：

圖 2. Docker Image Layer 的疊加

2 Docker Image 衍生單一 Base Image

隨著項目基于 Docker 的使用逐漸增加，Docker Image 的數量也將逐漸增加。隨之而來的問題就是如何維護這些 Docker Image 的升級。如果缺乏規劃和設計，每個 Docker Image 均來自一個最基礎的 OS Image，那么就需要對于所有的 Docker Image 進行重構。如圖 3所示：

圖 3. Docker Image 衍生單一 Base Image

當環境進行更新升級的時候，如果所有的節點均來自一個基礎的 OS Image，重復的 layer 層將會被重復更新。也就意味著，這部分重復的內容會被反復的下載。如果一個 Docker Image 達到了 1G 以上的規模，而每個 Docker Host 節點的更新都需要重新下載新的 Image. 這樣環境更新所花費的時間將會是成倍的增加。如圖 4 所示，Docker Image 2 和 Docker Image3 均是基于 Docker Image 1。

圖 4. 基于同樣 Base Image 的 Docker Image Layer 的疊加

圖 5. Docker Image Layer 在 Docker Host 上的存儲關系

從圖 5 可以看出在同一個 Docker host 上 download 來自同樣 Base Image 的 Docker Image, Docker 在下載 Image layer 的時候，對于已經存在的 layer 是不會重復下載的。但是如果 layer 不同，即使內部包含的內容一樣，也還是會重復下載的。

3.利用分層機制優化 Docker Image

通過上兩節的介紹，可以發現缺乏良好設計的 Docker Image 會給日后的維護以及我們后續CICD的效率帶來較大的問題。接下來就介紹下如何利用分層機制對項目的 Docker Image 進行合理的規劃。從而提升 Docker 在CICD過程中的可持續性，并提升CICD的效率。

3.1 設計基于分層機制的 Docker Image

假設系統中我們有兩個應用 App1 和 App2。這兩個節點的環境信息如下：

通過上表環境信息的對比，我們發現在這兩個不同引用的節點上，不同的部分只是 最后的代碼code 的和config 文件。對于其他相同的部分，我們可以考慮通過 Docker Image Layer 的概念將其復用。從而最大限度發揮 Docker 的能力。將上表中的兩部分環境信息以分類為節點名，重新以樹狀結構組織如圖 6 所示：

圖6.環境配置樹狀圖 1

建議將一些不會經常發生變化的命令或者同類型的命令，合并到同一層。如圖 7 所示：

圖7.環境配置樹狀圖 2

最后將圖中的兩個樹狀結構圖進行疊加將重復的節點進行合并，最后得出如下樹狀結構圖：

圖 8. 環境配置樹狀圖 3

現在我們已經基于 Docker Image 的分層存儲機制完成了一個初步的Docker Image 的規劃。接下來就可以根據上圖結構分別制作 Image。最終我們將會有三個 Base Image，和最終加入代碼的業務鏡像。同時基于此，我們的Dockerfile也類比如下：這里本該是 4個 gitlab 倉庫制作的 4個鏡像。為了方便展示鏡像復用關系， 用一個代碼塊展示：

# f1: 運維安全團隊增加優化基礎安全組件
FROM python3
RUN apt install -y some-security-framework
# push: abc.hub.com/libary/python3 

# f2: 架構師安裝基礎架構
FROM abc.hub.com/libary/python3
RUN wget -c anaconda12.sh && ./anaconda12.sh && rm -f anaconda12.sh
# push: abc.hub.com/ai-tools/env-anaconda:12

# f3: 制作模型鏡像
FROM abc.hub.com/ai-tools/env-anaconda:12
RUN pip install -y some-dependences
RUN wget -c s3.xx.com/some-path/dust.model -O /some/path
# push: abc.hub.com/ai-tools/env-anaconda-dust:runtime

# f4: 制作業務鏡像
FROM abc.hub.com/rk-ai-tools/env-anaconda-dust:runtime
ADD code /workspace/code
ENTRYPOINT [ "/bin/bash", "/entrypoint.sh" ]
# push: abc.hub.com/rk-ai-pollution/srv-some-appname-amd64:1.0.0-1234567

3.2 基于分層機制的 Docker Image 的實踐

如圖 10 所示, 按照之前介紹的安裝 Security tools/General tools/Library 的Docker Image 大小在 1.8 G 左右。以此為基礎創建的的 App Image 的大小在 1.9G 左右。

圖 10. Docker Image 分層存儲實驗 1

在一個已經 download 了 Liberty Docker Image 的環境下下載 App Image。如圖 11 所示，可以看到已經存在的 layer 已經是 complete 狀態。唯一 download 的部分只有新增加的 EAR 所產生的新的 layer。所需時間僅僅為 1 分 33 秒。

圖 11. Docker Image 分層存儲實驗 2

如果直接在一個不存在 Liberty Docker Image 的 server 上去 download App Docker Image, 如圖 12 所示，我們可以看到所需要的時間將超過 7 分鐘。

圖 12. Docker Image 分層存儲實驗 3

通過圖 13 可以發現其他 layer 的 download 時間要超過 4 分鐘，如果反復對這些重復的 Docker Image layer 進行下載更新，將會嚴重影響環境更新的效率。隨著不同 Image 之間在 Docker Image Layer 上的差異越大，所花費的下載 Docker Image 的代價也將越大。

圖 13. Docker Image 分層存儲實驗 4

4.小結

通過上文的描述和實際測試可知，如果我們能把鏡像做一個合理的分層，不但能縮短拉取鏡像的時間，提高CICD的效率，更能劃分不同團隊不同人員的角色，每個人只專注自己職責相關的鏡像，然后不同團隊或同團隊其他人員可以在其基礎上，再構建自己的鏡像，層層遞進，最終制作一個業務發布的鏡像。