理清容器標準和基金會：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，一個分布式的，可靠的鍵值存儲，可以用來存儲分布式系統中最關鍵的數據
</li> -
flannel，一個容器的虛擬網絡結構（network fabric）
</li> -
沒有被OCI覆蓋appc組件的，如鏡像格式和發現（discovery）
</li> -
和我們任何開源的項目，只要社區認為其以作為廠商中立的一部分而提供出來更合適（served as part of a vendor-neutral foundation）
</li> </ul>
一個很好的例子是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上努力。我們決心繼續在這條道路上迅速的往前沖鋒，在所有主要的兼容的操作系統和平臺上實現可互操作性和移植性，消除人為技術屏障。
本文轉載自: http://dockone.io/article/910
原文鏈接：Making Sense of Container Standards and Foundations: OCI, CNCF, appc and rkt（翻譯：鐘最龍）本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！