再談容器標準：CoreOS總結OCI、CNCF和AppC的發展
在CoreOS，我們堅信開放的標準對于建立容器生態來說至關重要。我們對于圍繞著容器和云原生計算的標準和基金會所投入的大量工作感到非常興奮，這也包括 關于Open Container Intialtive（OCI）的技術管理結構的確認。
過去的一年發生了很多事情，從App Container（AppC）規范和rkt，到Open Container Initialitive（OCI），再到Cloud Native Computing Foundation（CNCF）。今天，我們想花一點時間來清楚地闡述下我們眼中這些重要的項目未來將去往何處，以及我們想以怎樣的方式參與其中。盡管 OCI管理架構的確認有利于進一步地闡釋OCI的范圍，但要讓容器規范變得完整并且取得真正的可協作性，仍然需要更多的工作。
Open Container Initialtive（OCI）
當OCI（最初被稱作Open Container Project） 在今年六月宣布成立的時候，我們當時很高興能與Docker以及行業的伙伴們一起來推動容器的發展：“制定并維護容器鏡像格式和容器運行時的正式規范（“OCI Speicifications”），以達到讓一個兼容性的容器可以在所有主要的具有兼容性的操作系統和平臺之間進行移植，沒有人為的技術屏障的目標 （artificial techinical barriers）。” - OCI憲章OCI背后的想法是融合Docker和appc，并構建一個開放的標準。我們當時很快接受了這個愿景，因為有一個共享的標準對于生態圈的構建來說至關重要，標準可以讓整個容器生態健康發展。
盡管初看起來，OCI和appc之間有一些交叉的地方，但是OCI過去只是僅僅關注于runtime，比起我們對于項目的更大的期許，現在OCI 只做了一點點。我們努力引入的容器鏡像和鏡像distribution并沒有被接納，但是我們仍然相信它們是容器的標準的重要組成部分。
OCI和appc交叉的地方
盡管我們很高興行業已經聚到一起來支持OCI runtime，CoreOS相信容器標準最重要的一方面是可分發的（ distributable） 的容器鏡像：即可以給最終用戶可移植性的這一部分。這一部分目前OCI沒有解決，這也是為什么appc會繼續在這方面投入的原因。假若有了一個標準的鏡像 格式，用戶可以一次性構建/打包他們的容器，署上簽名，然后可以放到不同廠商的實現和平臺上運行。這意味著，舉個例子，用戶可以通過docker 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）
- 任何一個我們可以提供的開源項目 </ul>
一個很好的例子是etcd，CoreOS期待它能推動CNCF的發展。在過去兩年里，etcd已經被很多不同的項目使用。我們希望etcd能作為 互聯網的基本工具，就像Linux和Apache HTTP Web服務器一樣。如果把etcd放到基金會中能推動etcd的發展和應用，我們愿意這樣做。一切，只是為了更好。
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已經完成了標準的指定，并且假設rkt和Docker都支持它，那Intel就可以只需要 一次構建exec驅動，就可以供rkt和docker的實現使用了。
和Docker的互操作性（interoperability）
我們致力于讓rkt繼續可以和Docker保持互操作性，不管正式的標 準化是否存在。這意味著你可以用Docker構建鏡像，然后用rkt來運行。目前OCI并沒有覆蓋到這些格式 - 這意味仍需要工具來將Docker的特定實現，轉換成符合開放標準的格式。我們會繼續和行業一起努力爭取有一個共享的標準鏡像格式，但是在這之前，我們會 決心無論如何和Docker保持互操作性。邁步向前
加入我們一起繼續我們在OCI、CNCF和appc上努力。我們決心繼續在這條道路上迅速的往前沖鋒，在所有主流的操作系統和平臺上實現可互操作性和移植性，消除人為的技術屏障。原文鏈接：Making Sense of Container Standards and Foundations: OCI, CNCF, appc and rkt（翻譯：鐘最龍）
來自：http://dockone.io/article/910
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！