docker 的oci標準

OCI 和容器標準

容器技術隨着 docker 的出現煊赫一時，全部的技術公司都積極擁抱容器，促進了 docker 容器的繁榮發展。容器一詞雖然口口相傳，但卻沒有統一的定義，這不只是個技術概念的問題，也給整個社區帶來一個陰影：容器技術的標準究竟是什麼？由誰來決定？

不少人可能以爲 docker 已經成爲了容器的事實標準，那咱們以它做爲標準問題就解決了。事情並無那麼簡單，首先是否表示容器徹底等同於 docker，不容許存在其餘的容器運行時（好比 coreOS 推出的 rkt）；其次容器上層抽象（容器集羣調度，好比 kubernetes、mesos 等）和 docker 緊密耦合，docker 接口的變化將會致使它們沒法使用。

總的來講，若是容器以 docker 做爲標準，那麼 docker 接口的變化將致使社區中全部相關工具都要更新，否則就沒法使用；若是沒有標準，這將致使容器實現的碎片化，出現大量的衝突和冗餘。這兩種狀況都是社區不肯意看到的事情，OCI（Open Container Initiative） 就是在這個背景下出現的，它的使命就是推進容器標準化，容器能運行在任何的硬件和系統上，相關的組件也沒必要綁定在任何的容器運行時上。

官網上對 OCI 的說明以下：

An open governance structure for the express purpose of creating open industry standards around container formats and runtime. – Open Containers Official Site

OCI 由 docker、coreos 以及其餘容器相關公司建立於 2015 年，目前主要有兩個標準文檔：容器運行時標準 （runtime spec）和 容器鏡像標準（image spec）。

這兩個協議經過 OCI runtime filesytem bundle 的標準格式鏈接在一塊兒，OCI 鏡像能夠經過工具轉換成 bundle，而後 OCI 容器引擎可以識別這個 bundle 來運行容器。

下面，咱們來介紹這兩個 OCI 標準。由於標準自己細節不少，並且還在不斷維護和更新，若是不是容器的實現者，沒有必須對每一個細節都掌握。因此我以介紹概要爲主，給你們有個主觀的認知。

image spec

OCI 容器鏡像主要包括幾塊內容：

• 文件系統：以 layer 保存的文件系統，每一個 layer 保存了和上層之間變化的部分，layer 應該保存哪些文件，怎麼表示增長、修改和刪除的文件等

• config 文件：保存了文件系統的層級信息（每一個層級的 hash 值，以及歷史信息），以及容器運行時須要的一些信息（好比環境變量、工做目錄、命令參數、mount 列表），指定了鏡像在某個特定平臺和系統的配置。比較接近咱們使用 docker inspect <image_id> 看到的內容

• manifest 文件：鏡像的 config 文件索引，有哪些 layer，額外的 annotation 信息，manifest 文件中保存了不少和當前平臺有關的信息

• index 文件：可選的文件，指向不一樣平臺的 manifest 文件，這個文件能保證一個鏡像能夠跨平臺使用，每一個平臺擁有不一樣的 manifest 文件，使用 index 做爲索引

runtime spec

OCI 對容器 runtime 的標準主要是指定容器的運行狀態，和 runtime 須要提供的命令。下圖能夠是容器狀態轉換圖：

• init 狀態：這個是我本身添加的狀態，並不在標準中，表示沒有容器存在的初始狀態

• creating：使用 create 命令建立容器，這個過程稱爲建立中

• created：容器建立出來，可是尚未運行，表示鏡像和配置沒有錯誤，容器可以運行在當前平臺

• running：容器的運行狀態，裏面的進程處於 up 狀態，正在執行用戶設定的任務

• stopped：容器運行完成，或者運行出錯，或者 stop 命令以後，容器處於暫停狀態。這個狀態，容器還有不少信息保存在平臺中，並無徹底被刪除