理清容器标準和基金會：OCI，CNCF，appc 和 rkt

在coreos，我們堅信開放的标準對于容器生态環境的成功至關重要。我們對于圍繞着容器和雲原生計算的标準和基金會所投入的大量工作感到非常興奮，這也包括今天關于open container intialtive（oci）的技術管理結構的正式制定公告。

過去的一年事情進展很快，從app container(appc)規範和rkt，到open container initialitive（oci），再到cloud native computing foundation（cncf）。今天，我們想花一點時間來清楚地闡述下我們眼中這些重要的項目未來将去向何處，以及我們想以怎樣的方式參與其中。盡管 今天的公告有利于進一步地闡釋oci的範圍，要讓容器規範變得完整并且取得真正的可協作性，仍然需要更多的工作。

open container initialtive（oci）

當oci（最初被稱作open container project）在今年六月宣布成立的時候，我們當時很高興能與docker以及行業的一大部分(成員)作為合作夥伴一起來：

“制定并維護容器鏡像格式和容器runtime的正式規範（“oci speicifications”），以達到讓一個相容性的容器可以在所有主要的具有相容性的作業系統和平台之間進行移植，沒有人為的技術屏障的目标 （artificial techinical barriers）。” - oci憲章

oci 背後的想法是将來自docker廣泛部署的runtime和鏡像格式實作拿出來，遵照appc的精神制定一個開放的标準。我們當時很快接受了這個願景，因 為有一個共享的标準是一個獨二無二的機遇，可以促進容器的大範圍的增生和吸收度（wide proliferation and adoption），和一個存在互相競争的實作的健康生态系統。

盡管初看起來，oci和appc之間有一些交叉的地方，但是oci過去隻是僅僅關注于runtime，比起我們對于項目的更大的期許，其對于項目 關注的範圍更狹窄一些。我們努力引入容器鏡像和鏡像發放沒被納入（incorporated），但是我們仍然相信它們是容器的标準的重要組成部分。

oci和appc交叉的地方

盡管我們很高興行業已經聚到一起來支援oci runtime，coreos相信容器标準最重要的一方面是可分發的（distributable） 的容器鏡像：即可以給最終使用者可移植性的這一部分。這一部分目前沒有被oci解決，這就是我們會繼續同appc一起的努力很重要的原因。假若有了一個标準 的鏡像格式，使用者可以一次性建構/打包他們的容器，署上簽名，然後可以放到不同廠商的實作和平台上運作。這意味着，舉個例子，使用者可以通過dockier build構 建容器，然後可以在rkt，amazon ec2 container service（ecs），kubernetes或mesos上運作，所有這些平台都不需要重新打包。我們相信這是容器實作标準化最重要的一方面，是以我 們想就此繼續讨論，誠邀來自社群的成員加入我們。

鏡像分發和發現（discovery）是另一個容器标準的中我們相信很重要的領域。通過制定一個廠商中立（vendor-neutral），聯合的 （federated）協定，通過規定容器應該以什麼方式制定命名空間，怎樣被發現以及怎樣被下載下傳，我們們可以給最終使用者提供一個統一的視角 （federated view），同時消除廠商鎖定（vendor lock-in），并且鼓勵多樣化的實作。我們認為像git這樣 的工具在這方面做的相當出色。github是一個相當流行中心化倉庫，這讓使用者分享項目變得十分友善，但是git協定自身比并沒有在任何方面有任何的對 github的偏好。這種模式開放了一個可以競争的場地，這最終會讓使用者受惠。

clound native computing foundation（雲原生計算基金會）

cncf成立的目的來建構“雲原生”計算并促進其采用，這是一種圍繞着微服務，容器和應用動态排程的以基礎設施架構為中心的方式。這種風格的基礎設施我們稱為“fifee”：為其他所有人的google基礎設施（google's infrastrure for everyone else）。

我們創辦coreos是為了從根本上改善internet的安全性，而雲原生架構是讓這變為現實至關重要的一環。是以我們十分願意貢獻出任何向cncf建構的任何開源項目，這些項目對于這種樣式的基礎設施的進一步采用是很重要的。這包括：

etcd，一個分布式的，可靠的鍵值存儲，可以用來存儲分布式系統中最關鍵的資料

flannel，一個容器的虛拟網絡結構（network fabric）

沒有被oci覆寫appc元件的，如鏡像格式和發現（discovery）

和我們任何開源的項目，隻要社群認為其以作為廠商中立的一部分而提供出來更合适（served as part of a vendor-neutral foundation）

一個很好的例子是etcd，coreos将其建構來促進雲原生計算的吸收。在過去兩年裡，etcd已經夠背時和被很多不同的項目使用。我們想 etcd作為基本的網際網路，如linux和apache http web伺服器。如果将etc放在基本的位置讓其他的公司更加的容易，甚至對于我們的競争者來共享項目，并幫助其走向成功，我們願意做此共貢獻。

rkt：共同的标準需要多樣的實作

coreos緻力于将rkt開發成最安全和可随時投入生産環境的容器引擎。随着标準化在容器生态中的 來臨，rkt的存在變得更加的重要：标準需要多樣實作才會走向成功。早在web時代，整個行業圍繞着一單獨的web浏覽器轉動，其占據了統治地位的市場份 額：我們一開始有netscape的web，然後ie的web，它們都沒有過真的開放性和可互操作性（interoperable）。直到其他浏覽器的湧 現并占據了不少的市場佔有率 - firefox，chrome，safari - 然後web标準才開始起作用。同樣的道理，rkt是我們建立一個高度差異化的但仍是一個基于标準的容器runtime的努力，我們要保證在采用容器生态的 整個過程中将可互操作性（interoperability）和移植性放到很高的優先級。

随着oci将低層次的runtime層标準化，rkt和docker将會能共享執行一個容器的插件（plug-ins）。比如，intel最近通 過它們clear container項目，貢獻了其對于rkt的intel® virtualization technology支援，其可以讓容器被透明的包裹硬體虛拟化中 - 這為任何的容器runtime提供了最好形式的隔離。如果oci過去到位了（in place），并且假設rkt和docker都支援它，那intel就可以隻需要一次建構exec驅動，就可以供rkt和docker的實作使用了。

和docker的互操作性（interoperability）

我們緻力于讓rkt繼續可以和docker保持互操作性，不管正式的标 準化是否存在。這意味着你可以用docker建構你的鏡像，然後用rkt來運作。目前oci它們沒有覆寫到這些格式 - 這意味仍需要工具來來将docker特定的實作，來轉換成符合一個開放的标準的格式。我們會繼續和行業一起努力争取有一個共享的标準鏡像格式，但是在這之 前，我們會決心無論如何和docker保持互操作性。

邁步向前

加入我們與我們一起繼續我們在oci，cncf和appc上努力。我們決心繼續在這條道路上迅速的往前沖鋒，在所有主要的相容的作業系統和平台上實作可互操作性和移植性，消除人為技術屏障。

====================================分割線================================