本文轉載自微信公眾號「云巔論劍」，作者Liu,Bo 。轉載本文請聯系云巔論劍公眾號。 

容器鏡像中那些讓人一言難盡的事情

現如今容器生態大受歡迎有許多原因，其中一個就是應用部署上的優秀體驗，容器鏡像的出現是這種體驗能夠成為現實的一個基礎。

簡要回顧一下容器鏡像，概括為幾點：

1. 它提供了一個應用軟件運行的完整操作系統包，是不可變基礎設施的一部分，其格式(https://docs.docker.com/storage/storagedriver/?spm=ata.13261165.0.0.567e1b43DoMXC0)如下圖1 所示。
2. 鏡像中一個重要的概念是layer，引用docker documentation(https://docs.docker.com/storage/storagedriver/?spm=ata.13261165.0.0.567e1b43DoMXC0#images-and-layers)中的介紹，"Each layer is only a set of differences from the layer before it. The layers are stacked on top of each other."
3. 一個容器鏡像是由一個或多個layer組成的。
4. 容器鏡像是存儲在registry中的，諸如 Docker Hub(https://hub.docker.com/?spm=ata.13261165.0.0.567e1b43DoMXC0)和公有云提供商的registry service。

但今天我們要一起來吐槽一下容器鏡像。

1. 首次啟動中大型鏡像很慢

第一次運行時總是需要等上幾分鐘，這是因為在正式啟動一個容器之前，還需要一些準備工作：

1. 從registry下載鏡像，包含了鏡像的所有layers，比如上圖的鏡像"rust:latest"中包含6 layers，
2. 把鏡像layers一個接一個地解壓到本地filesystem中，
3. 最后用overlayfs 將這些layer組合為一個mount point作為容器的rootfs，
4. 啟動容器。

其中，當啟動一個龐大的鏡像時，最耗時的是第一步中的下載鏡像，但因為單一layer是一個整體，對同一個layer無法并行下載，與此同時鏡像size很大通常意味著包含的layer size也很大，所以大部分時間都花在了網絡傳輸上。

2. 去重低效

如果大家關注過鏡像base layer，比如上圖中的CentOS 和 Ubuntu，其中的目錄結構是相同的標準操作系統根分區結構，內容也是類似的，那么我們很自然地可以想到，在registry中存儲的時候會將他們去重(Deduplication)嗎?

對于上圖這種情況，registry 現在不會做去重，原因仍是“單一layer是一個整體”，registry 的去重是基于layer的digest id的，即如果兩個不同鏡像使用了同一個layer，那么在registry上只存一個layer。

3. 對刪除和鏈接的處理

先說刪除，當對lower layer中的一個file做unlink時，會在upper layer 發生什么?

現在的邏輯是在upper layer添加一個特殊的white-out empty file來表示被unlink的file，以達到最終視圖上的unlink效果。

“你說你一個沒點，完事我們還得搭一個是不"

想象一下，如果想刪掉一個password file，這個white-out 做法會帶來什么后果?

再說hardlink，當對lower layer中的一個file做hardlink時，會在upper layer發生什么?當前采取了一種笨拙的做法，即把lower layer file拷貝一份到upper layer，再添加對應的hardlink。當這個file size 很大時，那么浪費的存儲空間就相當可觀了。

4. 安全審計不完整

再說一個安全審計上的問題，因為鏡像每一個layer都有對應的digest id，在鏡像下載之后可以對layer進行校驗，但當把鏡像layers一個接一個地解壓到本地filesystem中之后呢?我們沒有辦法再去校驗了，因為本質上解壓后的filesystem目錄和鏡像的layers是兩種不同的形態了，所以運行時的安全審計是缺失的。

成也layer，敗也layer

我們回過頭來看，上面的問題除了最后的安全審計，其它的原因都可以歸結為“以layer為基本單位的鏡像格式”。所以，雖然選擇layer的設計是為了讓不同的應用軟件鏡像能夠共用同一部分基礎系統，達到節省存儲和節省傳輸的目的，但是在實踐中用戶們也逐漸發現了它帶來的難以workaround的問題。

欲知詳情，且聽明天分解。。。