5分鐘！帶你吐槽容器鏡像中那些讓人一言難盡的事情
本文轉載自微信公眾號「云巔論劍」，作者Liu,Bo 。轉載本文請聯系云巔論劍公眾號。
容器鏡像中那些讓人一言難盡的事情
現如今容器生態大受歡迎有許多原因，其中一個就是應用部署上的優秀體驗，容器鏡像的出現是這種體驗能夠成為現實的一個基礎。
簡要回顧一下容器鏡像，概括為幾點：
- 它提供了一個應用軟件運行的完整操作系統包，是不可變基礎設施的一部分，其格式(https://docs.docker.com/storage/storagedriver/?spm=ata.13261165.0.0.567e1b43DoMXC0)如下圖1 所示。
- 鏡像中一個重要的概念是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."
- 一個容器鏡像是由一個或多個layer組成的。
- 容器鏡像是存儲在registry中的，諸如 Docker Hub(https://hub.docker.com/?spm=ata.13261165.0.0.567e1b43DoMXC0)和公有云提供商的registry service。
但今天我們要一起來吐槽一下容器鏡像。
1. 首次啟動中大型鏡像很慢
第一次運行時總是需要等上幾分鐘，這是因為在正式啟動一個容器之前，還需要一些準備工作：
- 從registry下載鏡像，包含了鏡像的所有layers，比如上圖的鏡像"rust:latest"中包含6 layers，
- 把鏡像layers一個接一個地解壓到本地filesystem中，
- 最后用overlayfs 將這些layer組合為一個mount point作為容器的rootfs，
- 啟動容器。
其中，當啟動一個龐大的鏡像時，最耗時的是第一步中的下載鏡像，但因為單一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的問題。
欲知詳情，且聽明天分解。。。
