鏡像對容器部署的挑戰

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

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

容器鏡像加速服務 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 鏡像不會被解壓到本地，同時能夠對每一次數據訪問進行校驗，若是數據被篡改，則能夠從遠端數據源從新拉取。less

將來規劃

前面咱們介紹了 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」