再谈容器标准：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）
• 任何一个我们可以提供的开源项目

一个很好的例子是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上努力。我们决心继续在这条道路上迅速的往前冲锋，在所有主流的操作系统和平台上实现可互操作性和移植性，消除人为的技术屏障。