近日，螞蟻聯合阿里雲宣佈開源容器鏡像加速服務Nydus，並加入由阿里開源的CNCF孵化項目Dragonfly，共同構建雲原生技術生態。本文我們來一起了解下這個項目的技術原理與架構，歡迎合作交流。

鏡像對容器部署的挑戰

在容器的生產實踐中，偏小的容器鏡像能夠很快的部署啟動。當應用的鏡像達到幾個GB以上的時候，在節點上下載鏡像通常會消耗大量的時間。Dragonfly 通過引入 P2P 網絡有效的提升了容器鏡像大規模分發的效率。然而，用戶還是必須等待鏡像數據完整下載到本地，然後才能創建自己的容器。我們希望進一步縮減鏡像下載的時間，讓用戶能夠更快地部署容器應用。同時，如何更好的保護用戶的數據，也是容器行業近年來的重要關注點。

為此，我們為Dragonfly項目引入了一個容器鏡像加速服務 nydus 。nydus 能夠極大縮短鏡像下載時間，並提供端到端的鏡像數據一致性校驗，從而讓用戶能夠更安全快捷地管理容器應用。nydus 由阿里雲和螞蟻集團的工程師合作開發，並大規模部署在內部的生產環境中。作為雲原生生態的一部分， nydus 在生產環境的優秀表現，讓我們有信心現在將項目開源，讓更多的容器用戶能夠體驗到容器快速啟動和安全加載方面的能力。
https://github.com/dragonflyoss/image-service

Nydus: Dragonfly 的容器鏡像服務

nydus 項目優化了現有的 OCI 鏡像標準格式，並以此設計了一個用戶態的文件系統。通過這些優化，nydus 能夠提供這些特性：

• 容器鏡像按需下載，用戶不再需要下載完整鏡像就能啟動容器
• 塊級別的鏡像數據去重，最大限度為用戶節省存儲資源
• 鏡像只有最終可用的數據，不需要保存和下載過期數據
• 端到端的數據一致性校驗，為用戶提供更好的數據保護
• 兼容 OCI 分發標準和 artifacts 標準，開箱即可用
• 支持不同的鏡像存儲後端，鏡像數據不只可以存放在鏡像倉庫，還可以放到 NAS 或者類似 S3 的對象存儲上
• 與 Dragonfly 的良好集成

架構上， nydus 主要包含一個新的鏡像格式，和一個負責解析容器鏡像的 FUSE 用戶態文件系統進程。

nydus 能夠解析 FUSE 或者 virtiofs 協議來支持傳統的 runc 容器或者 Kata 容器。容器倉庫，OSS 對象存儲，NAS，以及 Dragonfly 的超級節點和 peer 節點都可以作為 nydus 的鏡像數據源。同時， nydus 還可以配置一個本地緩存，從而避免每次啟動都從遠端數據源拉取數據。

鏡像格式方面， nydus 把一個容器鏡像分成元數據和數據兩層。其中元數據層是一顆自校驗的哈希樹。每個文件和目錄都是哈希樹中的一個附帶哈希值的節點。一個文件節點的哈希值是由文件的數據確定，一個目錄節點的哈希值則是由該目錄下所有文件和目錄的哈希值確定。每個文件的數據被按照固定大小切片並保存到數據層中。數據切片可以在不同文件以及不同鏡像中的不同文件共享。

Nydus 能為用戶帶來什麼？

用戶如果部署了 nydus 鏡像服務，最直觀的一個感受就是，容器啟動變快了，從以前的明顯時間消耗，變成了幾乎瞬間就能啟動起來。在我們的測試中， nydus 能夠把常見鏡像的啟動時間，從數分鐘縮短到數秒鐘。

另外一個不那麼明顯但也很重要的改進，是 nydus 能夠為用戶提供容器運行時數據一致性校驗。在傳統的鏡像中，鏡像數據會先被解壓到本地文件系統，再由容器應用去訪問使用。解壓前，鏡像數據是完整校驗的。但是解壓之後，鏡像數據不再能夠被校驗。這帶來的一個問題就是，如果解壓後的鏡像數據被無意或者惡意地修改，用戶是無法感知的。而 nydus 鏡像不會被解壓到本地，同時可以對每一次數據訪問進行校驗，如果數據被篡改，則可以從遠端數據源重新拉取。

未來規劃

前面我們介紹了 nydus 的架構和優點。在過去的一年裡，我們和內部的產品團隊一起致力於讓 nydus 項目更穩定，安全和易用。在把 nydus 項目開源之後，我們將會更關注廣泛的雲原生容器生態。我們的願景是，當用戶在集群中部署 Dragonfly 和 nydus 服務的時候，無論鏡像大小，用戶都能夠方便快捷地運行他們的容器應用，同時不需要為容器鏡像的數據安全性擔憂。

OCI 社區容器鏡像標準

雖然我們已經在內部生產環境中大規模部署 nydus，我們堅信對 OCI 鏡像標準的改進需要廣泛的社區合作。為此，我們積極地參與了 OCI 社區關於下一代鏡像標準的討論，並發現 nydus 能夠廣泛地符合 OCI 社區對下一代鏡像格式的要求。所以我們提議把 nydus 作為 OCI 社區下一代鏡像格式的示例實現，並期待和更多的雲原生行業領導者們一起推進下一代鏡像標準的制定和實現。

FAQ

Q: 現有的 OCI 鏡像標準有什麼問題？
SUSE 的 Aleksa Sarai 寫過一個 blog (The Road to OCIv2 Images: What's Wrong with Tar?)，詳細地描述了現有 OCI 鏡像標準的一系列問題，簡單總結就是 OCI 鏡像標準使用的 tar 格式太古老並不適合作為容器鏡像格式。

Q: nydus 和 CRFS 有什麼區別？
CRFS 是 GO build team 設計的一個鏡像格式。二者在主要設計思想上非常相似。細節上， nydus 支持塊級別的數據去重和端到端的數據一致性校驗，可以說是在 CRFS 的 stargz 格式上的進一步改進。

Q: nydus 和 Azure 的 Teleport 有什麼區別？
Azure Teleport 更像是現有 OCI 鏡像標準在基於 SMB 文件共享協議的 snapshotter 上的一個部署實現，能夠支持容器鏡像數據按需下載，但保留了所有目前 OCI 鏡像 tar 格式的缺陷。相對的， nydus 拋棄了過時的 tar 格式，並使用 merkle tree 格式來提供更多的高級特性。

Q: 如果運行基於 nydus 的容器的時候網絡斷了怎麼辦？
使用現有 OCI 鏡像的時候，如果在容器鏡像還沒有完整下載的時候網絡斷了，容器會一開始就無法啟動。nydus 很大程度上改變了容器啟動的流程，用戶不需要再等待鏡像數據完整下載就能啟動容器。而容器運行時如果網絡斷了，將無法訪問沒有下載到本地的鏡像數據。nydus 支持在容器啟動後在後臺下載容器鏡像數據，所以當容器鏡像數據完整下載到本地後，基於 nydus 的容器也不會受到網絡中斷的影響。

附錄：OCIv2 鏡像標準

從 2020 年 6 月開始，OCI 社區花了一個多月時間密集討論了當前 OCI 鏡像標準的缺陷，以及 OCIv2 鏡像格式需要滿足哪些要求。OCIv2 在這裡只是一個宣傳命名，實際上 OCIv2 是當前 OCI 鏡像標準的改進，而不會是一個全新的鏡像標準。

這次鏡像格式大討論從一個郵件和一份共享文檔開始，並促成了多次在線的 OCI 社區討論會議。最後的結論也很鼓舞人心，OCIv2 鏡像格式需要滿足下列要求：

• 更少的重複數據
• 可重建的鏡像格式
• 明確的更少的文件系統元數據
• 可以 mount 的文件系統格式
• 鏡像內容列表
• 鏡像數據按需加載
• 可擴展性
• 可校驗和/或可修復
• 更少的上傳數據
• 可以工作在不可信存儲上

在這份共享文檔中可以找到每一個要求的詳細描述。我們全程參與了整個 OCIv2 鏡像格式要求的討論，並發現 nydus 很好地滿足了全部的這些要求。這進一步促使我們開源 nydus 項目來為社區討論提供一個工作的代碼基礎。
https://hackmd.io/@cyphar/ociv2-brainstorm