CoreOS应用程序容器规范获得谷歌、Apcera和红帽的支持

......公司和个人都聚集在一起，确保应用程序容器有一个明确定义的规范，提供指导，以确保堆栈之间的安全性、开放性和模块化。

这对于Kubernetes项目和更广泛的容器社区来说，都是向前迈出的重要一步。这为容器的表达力添加了灵活性和选择，也为Kubernetes开发者带来了令人信服的新的安全性和性能的保证。

尽 管Apcera的HCOS还继续是关于安全性和政策，但是Kurma是基础的容器环境，作为HCOS部署的基石，可以提高运行效率。AppC对我们变得有 吸引力，[......因为......]象网络本身、图像发现、图像验证和加密、以及应用程序标识这些都是我们关心的议题

这组新的维护人员带来了各自独特的视角，使appc成为真正的协作。

Boulle： 自从我们最初开始开发appc规范和rkt，我们就与Apache Mesos的团队保持密切联系－－既有在Mesosphere本身的，也有在推ter的，那里也有很多核心的开发工作。他们提供了很多有用的意见，同时也在Mesos本身内部积极地致力于该规范自己的实现。这正好符合他们倾向于把功能集成到Mesos核心中的架构模型。这也恰好是我们试图要用该规范实现的绝佳例子：明确定义的标准，又有各种不同的、可互操作的实现。把appc直接包含到Mesos的核心中，这意味着所有在Mesos平台上运行的框架 －－Mesosphere的Marathon、Apache Aurora和其它框架－－都可以利用它了。

我们也在积极地与其它集群管理框架产品讨论与appc和rkt的集成，敬请关注！

Boulle： 当最初开发这个规范时，我们特意对这两个方面保持无关－－特别是网络，这是个异常复杂的话题，因为每个环境都有其独特、深奥的要求。我们不想在规范中过多地规定这些，所以我们只是保持在一个很简单的水平上，只是说运行库需要为应用程序容器提供可用的第3层网络接口。

随着我们自己开始实现规范的工作，我们很明确地需要找到一个具体的网络解决方案，既要能够用于rkt，又要能够提供满足这些不同需求的灵活性。为此我们与社区（他们提供了很多非常有用的信息！）协作，制定了一个基于插件的网络提案－－基本想法是，可以开发独立的插件，与各种不同的网络后端接口，从云供应商的技术，到最新的 Linux内核功能，比如ipvlan。我们的网络大师Eugene，也是flannel项目背后的主要开发人员，随后实现了这个网络功能，并把它集成到 rkt之中。

但是随着rkt网络提案的成熟，来自社区的关键反馈之一是，这似乎是超出rkt本身以外的处理网络更加普遍有用的方式。同时我们开始听到行业内其他人的声音－－象红帽的OpenShift工程师，以及谷歌的Kubernetes团队－－他们也有兴趣尝试用于他们的项目的、类似的基于插件的解决方案。

你也许知道，在CoreOS这里我们是开放、通用标准的铁杆粉丝，看到行业内有这样对看起来可以共享的东西的强烈需 求，促使我们想要为此做些什么。如果我们能够合并为一个共享的标准，并充分利用通用的、可以互操作的资源，这对整个行业和容器生态环境的成功都将产生难以估量的作用。所以我们最近创建了我们最初称之为容器网络接口(CNI，Container Network Interface）的东西，这是一个为Linux上的应用程序容器定义网络插件的规范。虽然现在我们决定把它发布在GitHub上的appc组织之下， 但是这和appc规范本身完全不同，而且适用范围要小得多（就说一点，这是很明确的针对Linux的，而appc规范是要跨平台的）。我们在积极地与谷 歌、红帽和思科以及社区的其他成员合作，充实规范，并有希望能够很快达成一致，这样我们就可以开始把它集成到不同的项目中。

我想强调，虽然这还是一个建议中的规范，很大程度上还处于制定阶段，不过我们已经有了一些独立的具备完整功能的插件了，还有其它几个正在在积极地开发。实际上，我们已经 非常成功地把rkt本身迁移到使用CNI插件，而且在刚刚过去的几天中我们已经有一个社区成员为ipvlan添加了插件。

至于存储，这是我们还来不及有时间专注于其中的领域。现在我只能说，只要有可能，我们希望能够站在那些从事大型分布式系统的巨人的肩膀上－－象Kubernetes和Mesos－－利用他们的专业知识和经验，回馈到规范中。

Boulle： 在CoreOS，我们集中精力于建设良好定义的、高效的和高度可组合的组件，我们尽力使它们尽可能的可移植。我们肯定能够在嵌入式设备或物联网领域看到容器的一些有趣的应用。社区对这个领域有很大的兴趣：我们已经有用户在ARM设备上使用rkt和appc进行了尝试，为此我们最近在appc认可的标准架构 集合中添加了ARM v7和v8的架构。因为ARM的生态系统在历史上就是个很多样化的架构集，在象Linux那样的实现中对命名有一些分歧，我们很注意我们做这件事的方式是 正确的，所以我们与ARM的工程师一起工作来确保我们使用了适当的命名。

至于Windows，从一开始我们就希望appc是跨平台的规范，我们很乐意看到微软或者Windows社区的人进行实现。在发展规范的同时我们也很努力地实现无关性和可移植性之间的小心、务实的平衡，使规范的核心很通用，而又支持各操作系统特定的部分。

Boulle：appc 规范是开放的项目，我们邀请所有的公司－－真的是所有来自社区的人－－参与讨论，并形成规范。任何为规范积极贡献的个人都有资格被选为维护人员。重要的是，既然我们建立了管理政策，那么CoreOS就无法控制项目的命运，因为大部分维护人员来自（CoreOS）公司外部。

我们绝对欢迎 Docker团队的工程师参与该项目。开始显然可以针对规范的当前状态提出反馈，以及那些对Docker项目不太好的地方，然后可以与现有维护人员一起解决规范中的这些问题，为最终在Docker引擎本身中实现appc的支持而努力。现在有好几个appc运行库的实现处于积极开发的状态－－包括 jetpack、kurma和rkt－－我们已经知道我们能够共同商定一个规范，协调一致地开发功能各自独立的实现。所以，再多一组工程师实现规范，参与讨论，使之制定得尽可能的完善，这当然是令人欢迎的进步。

我们的目标是形成一个社区，大家都希望看到容器以各种可能使用的创造性的方式达到成功，并确保有一个共同的标准，以满足所有人的需求。

Boulle： 我要说，我们感到吃惊，因为我们强烈地认为，我们对容器生态系统的总体目标是一致的，我们是希望公开地解决这些问题，并能够合并成一个共同的解决方案。我们本来可以在第一个拉取请求（#10776）上说得更清楚，更明确地表达，这是一个单纯的概念证明，用来指导你提到的问题（#10777）中的讨论，并展 示我们是愿意贡献代码的。不幸的是，代码成了焦点，而不是我们希望促进的讨论。所以我们不得不承担一些我们没有从一开始就尽可能清楚表达的责任。

Boulle： 尽管容器这个领域尚处于（发展的）初期，我们还是相信某些问题在当前的多个实现中是可以标准化和共享的，这些就是我们试图在appc规范中定义的。围绕映 像格式、环境、命名、发现、版本控制、压缩和加密的问题都是熟知的领域，可以由一组工程师独立实现，分开讨论。

在这些问题上达成共识意味着，应用程序开发人员可以写一个appc容器的映像，在遵循该规范的任何地方运行。这是为什么在容器标准上达成一致是重要的的一个主要原因：使开发人员的工作更轻松，让他们可以使用各种工具以共通的格式互相操作。然后，要在生产环境中运行软件时，运营工程师可以选择任何遵循规范的运行库，并确信应用程序会 按照预期的方式运行。

的确，现在试图把容器化的基础架构相关的一切进行标准化——特别是当这个领域还是如此新兴时——会是困难的或者甚至是 不可能的。但是appc并没有打算把运行库或网络这样的东西标准化到细枝末节。与虚拟机这样的技术相比，容器包括一系列的实现决策，在规范中我们把这些抽象到更高的层次。我们打算保持appc规范的通用性，集中于当前的领域；象对外的API、资源层次结构的管理、网络的实现，等等，都肯定超出范围了。

Boulle：CoreOS 秉持“早发布，常发布”的理念，而且rkt仍是一个早期项目。说了这些，我们还在努力工作，让它达到我们有把握地认为是适合生产环境的阶段。有一点要注意，在v1.0之前，我们故意让rkt的主/次版本号落后于规范的版本号（明确它要实现哪个版本），所以rkt的发行版本号并不能代表它开发或成熟的进度。这也明显地意味着rkt依赖于规范的稳定，直到我们可以宣布1.0版本！

至于规范本身：随着最近任命CoreOS以外的其他维护人员， 我们现在有了其他人的共同帮助来使它完善。最近几周可以看到来自这些新加入的贡献者的显著进展，而且我们开始非常专注于达到1.0版本所必需的东西。当我 们达到这一里程碑时，这将是基于管理委员会的维护者以及更广泛的appc社区的共同努力。