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 命令之後，容器處於暫停狀態。這個狀態，容器還有很多信息保存在平臺中，並沒有完全被刪除