理清容器标准和基金会 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 背后的想法是将来自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保持互操作性。