讓容器應用管理更快更安全，Dragonfly 釋出 Nydus 容器鏡像加速服務

鏡像對容器部署的挑戰

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

為此，我們為 Dragonfly 項目引入了一個容器鏡像加速服務 Nydus。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

Q1：現有的 OCI 鏡像标準有什麼問題？

A1：SUSE 的 Aleksa Sarai 寫過一個 blog (The Road to OCIv2 Images: What's Wrong with Tar?)，較長的描述了現有 OCI 鏡像标準的一系列問題，簡單總結就是 OCI 鏡像标準使用的 tar 格式太古老，并不适合作為容器鏡像格式。

Q2：Nydus 和 CRFS 有什麼差別？

A2：CRFS 是 GO build team 設計的一個鏡像格式。二者在主要設計思想上非常相似。細節上， Nydus 支援塊級别的資料去重和端到端的資料一緻性校驗，可以說是在 CRFS 的 stargz 格式上的進一步改進。

Q3：Nydus 和 Azure 的 Teleport 有什麼差別？

A3：Azure Teleport 更像是現有 OCI 鏡像标準在基于 SMB 檔案共享協定的 snapshotter 上的一個部署實作，能夠支援容器鏡像資料按需下載下傳，但保留了所有目前 OCI 鏡像 tar 格式的缺陷。相對的，Nydus 抛棄了過時的 tar 格式，并使用 merkle tree 格式來提供更多的進階特性。

Q4：如果運作基于 Nydus 的容器的時候網絡斷了怎麼辦？

A4：使用現有 OCI 鏡像的時候，如果在容器鏡像還沒有完整下載下傳的時候網絡斷了，容器會一開始就無法啟動。Nydus 很大程度上改變了容器啟動的流程，使用者不需要再等待鏡像資料完整下載下傳就能啟動容器。而容器運作時如果網絡斷了，将無法通路沒有下載下傳到本地的鏡像資料。Nydus 支援在容器啟動後在背景下載下傳容器鏡像資料，是以當容器鏡像資料完整下載下傳到本地後，基于 Nydus 的容器也不會受到網絡中斷的影響。

附錄：OClv2 鏡像标準

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

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

• 更少的重複資料
• 可重建的鏡像格式
• 明确的更少的檔案系統中繼資料
• 可以 mount 的檔案系統格式
• 鏡像内容清單
• 鏡像資料按需加載
• 可擴充性
• 可校驗和/或可修複
• 更少的上傳資料
• 可以工作在不可信存儲上

在

共享文檔

中可以找到每一個要求的較長的描述。我們全程參與了整個 OCIv2 鏡像格式要求的讨論，并發現 Nydus 很好地滿足了全部的這些要求。這進一步促使我們開源 Nydus 項目來為社群讨論提供一個工作的代碼基礎。

共享文檔連結：

https://hackmd.io/@cyphar/ociv2-brainstorm

“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”