![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/5de5188ee7f4463bb2780159a5460fed.png)

作者 | Liu,Bo
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/yC-UmMSDja959K9i_jSucQ)

# 前言

常言道，startup 有 startup 的好，大廠有大廠的好，那麼大廠究竟好在哪呢？拿矽谷老牌大廠們 FLG 來說，如果要問最令人懷念的是什麼？Free food 和基礎設施(Infrastructure)一定是會上榜的，兩者均極大提升了廣大應用開發者的幸福指數。那麼能不能“讓天下沒有難做的應用”呢？請大家把目光投向正在興起的雲原生生態。

在雲原生生態中，容器服務包括了映象和容器引擎兩個部分。其中容器映象作為核心的雲原生應用製品，打包了完整的作業系統和應用執行環境，應用的迭代也因為使用了這種不可變架構而變得更簡單，更頻繁。

本文將圍繞著容器映象這一核心，分享它的相關知識和業界的思考與實踐。

## 容器映象的概念

### 1）容器映象

容器映象有一個官方的類比，"生活中常見的集裝箱"，雖然擁有不同的規格，但箱子本身是不可變的（Immutable），只是其中裝的內容不同。

對於映象來說，不變的部分包含了執行一個應用軟體（如 mysql）所需要的所有元素。開發者可以使用一些工具（如 Dockerfile）構建出自己的容器映象，簽名並上傳到網際網路上，然後需要執行這些軟體的人可以透過指定名稱（如 _example.com/my-app_）下載、驗證和執行這些容器。

### 2）OCI 標準映象規範

在 OCI 標準映象規範出1臺之前，其實有兩套廣泛使用的映象規範，分別是 appc 和 docker v2.2，但“合久必分，分久必合”，有意思的是兩者的內容已經在各自的發展中逐步同化了，所以 OCI 組織順水推舟地在 docker v2.2 的基礎上推出了 oci image format spec，規定了對於符合規範的映象，允許開發者只要對容器打包和簽名一次，就可以在所有的容器引擎上執行該容器。

這份規範給出了 OCI image 的定義：

```
This specification defines an OCI Image, consisting of a manifest, 
an image index (optional), a set of filesystem layers, and a configuration.
```

### 3）容器的工作流程

一個典型的容器工作流程是從由 developers 製作容器映象開始的（build），然後上傳到映象儲存中心（ship），最後部署在叢集中（run）。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/a94ca42d96bb4df2a40d92b48d82f5f5.png)

# 容器映象技術發展中遇到的問題

不得不說，容器映象的設計是很出彩的，首先它蘊含了“完整的作業系統就是一個包”的優秀思想，帶著大家跳出了安裝包的思路，又提出了諸如 dockerfile 這樣的提升開發者體驗的 killer features，還能利用分層結構來節約時間空間。

不過，"金無足赤，人無完人"，優秀的設計並不等於優秀的實踐，下面來聊一聊問題具體出在哪。

## 1. 容器映象使用者

### 1）問題一：啟動容器慢

容器啟動慢的情況普遍發生在當使用者啟動一個很大 size 的容器映象時，由於在容器準備階段需要三步（以 overlayfs 為例）：

- download 映象。

- unpack 映象。

- 使用 overlayfs 將容器可寫層和映象中的只讀層聚合起來提供容器執行環境。

其中，download 映象時需要 download 整個映象，不能實現檔案資料按需載入。再加上 download 映象本身受限於網路頻寬的影響，當容器映象 size 在到幾個 G 時，下載時間會較長，破壞了容器原本優秀的使用者體驗。

### 2）問題二：較高的本地儲存成本

不同映象之間可以共享的最小單位是映象中的層，它的缺點之一是在 deduplication 上的效率是較低的，原因是：

- 首先，層內部存在重複的資料。

- 其次，層與層之間可能存在大量重複的資料，但即使有微小的差別，也會被作為不同的層。

- 再次，根據 OCI image spec 對刪除檔案和 hardlink 的設計，一個映象內部可能存在已經被上層刪除的檔案仍然存在於下層中，幷包含在映象中。

所以，當不同映象的容器被排程到同一臺機器上執行時，映象本身在本地檔案系統中所佔的儲存空間是一筆不可忽視的成本開銷。

## 2. 映象提供者側

這裡的提供者主要指容器服務的映象中心。

### 1）問題一：巨大的儲存浪費

- 存在大量相似映象 造成這種情況有兩個原因：

- 首先，上面提到的層的缺點，在容器映象中心會產生許多相似映象。

- 其次，OCI image 使用了 tar+gzip 格式來表達映象中的層，而 tar 格式並不區分 tar archive entries ordering，這帶來一個問題，即如果使用者在不同機器上 build 去同一個映象，最終可能會因為使用了不同的檔案系統而得到不同的映象，然後使用者上傳之後，映象中心中會存在若干不同映象的實質內容是完全相同的情況。

- 映象去重效率低：雖然映象中心有垃圾回收來實現去重功能，但其仍然以層為單位，所以只能在有完全相同 hash value 的層之間去重。

### 2）問題二：雲原生軟體供應鏈帶來的新需求

隨著時間推移，和軟體供應鏈一起發展的還有對軟體供應鏈環節的多樣性攻擊手段。安全防護是軟體供應鏈中非常重要的組成，不光體現在對軟體本身的安全增強，也體現在對供應鏈本身的安全增強。而因為應用執行環境被前置到了容器映象中，所以對容器映象的安全，包括對映象的漏洞掃描和簽名成為了容器服務提供者的必要能力。

# 對容器映象的思考和討論

## 1. 業界的嘗試

針對前面所述的問題，業界大小廠也是集思廣益，各顯神通，下面提幾個典型的專案：

### 1）CernVM-FS

使用了 fuse 按需從遠端載入需要的資料。

### 2）Slacker

透過設計一個映象的 benchmark 貢獻了幾個有意思的理論基礎：

- 事實上，容器啟動時間很長。

- 啟動時資料讀寫放大係數很大（啟動時中只使用 6% 的資料）。

- 分析了 57 個 docker image 的 layer 數量，發現一半以上的 image 的 layer 數量大於 9。

Slacker 最終使用了按需載入和減少映象層數將啟動速度提高了 5-20 倍。

### 3）SquashFs

Oracle 使用 Linux SquashFS 來替代 targz 儲存容器 image layer 的內容，去掉了 unpack tar 的環節。

## 2. OCI 社群中的討論

自 2019 年開始，對於映象本身的吐槽慢慢多了起來，發酵了一年多，OCI 社群覺得時機成熟了，從 2020 年 6 月開始，花了一個多月時間密集討論了當前 OCI 映象規範的缺陷，以及 OCIv2 映象格式（*）需要滿足哪些要求。

（*）OCIv2 在這裡只是一個宣傳命名，實際上 OCIv2 是當前 OCI 映象規範的改進，而不會是一個全新的映象規範。

### 1）OCI 映象規範的缺陷

經過討論得出目前的缺陷主要有兩點：

- tar 格式標準
   - tar 格式並不區分 tar archive entries ordering，這帶來一個問題，即如果使用者在不同機器上去 build 同一個映象，最終可能會因為使用了不同的檔案系統而得到不同的映象，比如在檔案系統 A 上的 order 是 foo 在 bar 之前進入 tar，在檔案系統 B 上的 order 是 bar 在 foo 之前進入 tar，那麼這兩個映象是不同的。
   - 當 tar 被 gzip 壓縮過之後不支援 seek，導致 run container 之前必須先下載並解壓 targz 的 image layers，而不能實現檔案資料按需載入。

- 以層為映象的基本單位
   - 內容冗餘：不同層之間相同資訊在傳輸和儲存時都是冗餘內容，在不讀取內容的時候無法判斷到這些冗餘的存在。
   - 無法並行：單一層是一個整體，對同一個層既無法並行傳輸，也不能並行提取。
   - 無法進行小塊資料的校驗，只有完整的層下載完成之後，才能對整個層的資料做完整性校驗。
   - 其他一些問題：比如，跨層資料刪除難以完美處理。

### 2）下一代映象格式的要求

這次映象格式大討論從一個郵件和一份共享文件開始，並促成了多次線上的 OCI 社群討論會議。最後的結論也很鼓舞人心，在這份共享文件中可以找到對 OCIv2 映象格式需要滿足的要求的詳細描述。我們可以將這些要求分類為：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f6671e37708348128a9014536618a615.png)

（*）: 諸如 file timestamp 等只在一個特定機器上有意義的 metadata 是沒有必要存在於映象中的。

可以看出，上面這些要求明確了容器映象的下一步重點在易用、效率、安全三個方面，達到在 "build - ship - run" 這三個階段協同最佳化的目的。

## 3. 阿里雲在容器映象上的思考

阿里雲一直積極地推動和發展雲原生生態，提供了基礎設施“阿里雲容器映象服務（ACR）”作為使用者雲原生容器化的第一站，負責提供容器映象、Helm Chart 等 OCI Artifacts 管理和分發服務。同時我們也在結合容器業務現狀深化對容器映象格式的理解，不斷地總結什麼是滿足發展需求的容器映象格式，這裡可以概括為以下幾點，新的映象格式需要：

- 滿足容器 "build once, run anywhere" 的理念。
- 實現在映象中心和容器執行結點上儲存資源上的高效使用。
- 在容器映象的全鏈路上（build, ship, run）比現有的 OCI 映象格式速度更快。
- 能夠擴充套件在安全上的能力。
- 最大程度相容已有基礎設施，普惠大多數使用者。

# 阿里雲沙箱容器的映象加速

相比於社群的討論重點放在了新的映象格式的設計上，阿里雲更關心如何設計出一套最佳化全鏈路的映象方案，為客戶帶來能夠應用在生產中的價值。

在明確以上在技術發展過程中產生的需求之後，我們為[阿里雲沙箱容器](https://help.aliyun.com/document_detail/142151.html)設計了新的映象格式 Rafs，併為 CNCF 下的 Dragonfly 專案引入了容器映象服務，它能夠極大縮短映象下載時間，並提供端到端的映象資料一致性校驗，從而讓使用者能夠更安全快捷地管理容器應用。

### **1. Rafs: 映象格式**

Rafs 把一個容器映象只分成後設資料和資料兩層。其中：

- 後設資料層：後設資料層是一顆自校驗的雜湊樹。每個檔案和目錄都是雜湊樹中的一個附帶雜湊值的節點。一個檔案節點的雜湊值是由檔案的資料確定，一個目錄節點的雜湊值則是由該目錄下所有檔案和目錄的雜湊值確定。
- 資料層：每個檔案的資料被按照固定大小切片並儲存到資料層中。資料切片可以在不同檔案以及不同映象中的不同檔案共享。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/668491a519ee4b7496b5208bfa9c1287.png)

## 2. Nydus: Dragonfly 的容器映象服務

除了使用上面的映象格式 Rafs，Nydus 還包含一個負責解析容器映象的 FUSE 使用者態檔案系統程式。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/86ea892ea5434fe68ae034c4a2cf42a3.png)

nydus 能夠解析 FUSE 或者 [virtiofs](https://virtio-fs.gitlab.io/) 協議來支援傳統的 [runC 容器](https://github.com/opencontainers/runc)或者阿里雲沙箱容器。容器倉庫、[OSS 物件儲存](https://www.alibabacloud.com/zh/product/oss)、NAS、以及 Dragonfly 的超級節點和 peer 節點都可以作為 nydus 的映象資料來源。同時，nydus 還可以配置一個本地快取，從而避免每次啟動都從遠端資料來源拉取資料。

基於這個設計架構，nydus 分別在 build, ship, run 和相容性方面提供下面這些最佳化：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/d639eb931e114171bfb39532d473e577.png)

## 3. 為什麼選擇基於檔案的設計

在設計之初，Nydus 選擇了基於檔案的設計而不是基於塊的設計，為什麼這樣做呢？

主要的原因是，我們想在映象加速的基礎上做基於容器特點的附加能力，這一切都建立在能夠獲取到映象中的檔案後設資料；而基於塊的設計只使用 disk LBA，天然的無法獲取其上層（即檔案系統）中的資訊。

有了檔案後設資料之後，我們輕鬆地實現了以下幾個增值功能：

- 映象最佳化建議：在 build container 環節，提示使用者有哪些檔案是根本沒有訪問過的，可以考慮藉此來最佳化映象。
- 預讀：在 run container 環節預載入，猜到使用者要讀檔案，那就預先在讀操作發生之前送過去，從而最佳化訪問速度。
- 安全審計：在 run container 環節，如果一個容器訪問映象內容的模式和其他容器產生了明顯差異，那麼，這有可能是一個安全性風險。
- 變更風險發現：在 run container 環節，如果一個映象升級之後，發現它訪問內容的模式和之前發生了明顯差異，那麼，要麼是程式自己有意變了，要麼就可能是引入 bug 了，這時可以考慮提醒開發者這個變化。

# 總結

OCI image 分層映象機制雖然極大地方便了開發，但在大規模叢集執行時，也有頗多不足，對此，OCI 映象社群也在尋求著如何利用映象內容可感知性，讓它更加快速、節省資源，也更加安全。阿里雲在這個基礎上本著為客戶帶來價值的原則，提出了公有云上對映象的穩定性、預讀等需求，併為阿里雲沙箱容器研發出了相應的的映象加速方案，實現 "build-ship-run" 整個映象鏈路上的統一最佳化，讓使用者不光聽著熱鬧，也能用著開心，切實得到雲原生基礎設施發展的紅利。

對容器映象的思考和討論

相關文章