转载

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

在旧金山的首届 CoreOS Fest 上， CoreOS 团队宣布，应用程序容器规范（App Container specification，appc）最近获得了谷歌、Apcera、红帽和VMware的支持。谷歌在 Kubernetes 中增加了对CoreOS的appc实现 ‘rkt’ 的支持，Apcera创建了名为 ‘Kurma’ 的新的appc实现。appc的一项新的管理政策也已建立，除了CoreOS现有的维护人员，还从红帽、谷歌和Twitter挑选了维护人员。

自从2014年12月的应用程序容器规范宣布以来，CoreOS是官方推动规范发展的唯一公司。Appc提供了对如何构建和运行容器化的应用程序的定义，其重点在于安全性、可移植性和模块化。为了配合appc规范的定义，CoreOS还开发了容器运行库 rkt ，这是appc的首个实现。

CoreOS博客指出，随着堆栈之间的安全性和可移植性成为成功采用应用程序容器的核心，在CoreOS Fest上宣布谷歌、Apcera、红帽和VMware已经为这一工作提供了支持。

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

四月份谷歌风险投资公司牵头对CoreOS进行了1200万美元的投资，恰巧CoreOS的 Tectoni ，商用的 Kubernete 平台，也同时推出。Kubernetes 是谷歌的应用程序容器的开源业务流程调度系统，在计算集群内处理节点任务的调度，积极管理工作负荷。在CoreOS Fest上谷歌表示，现在已经接受了在Kubernetes项目中增加appc支持的拉取请求（pull request）。这意味着CoreOS的rkt（以及任何兼容appc的容器实现）现在可以同Docker容器一样在Kubernetes中运行。

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

Apcera发布了Kurma，为appc的工作增加了支持，这是appc的开源实现，从Apcera为容器化他们的混合云操作系统（Hybrid Cloud Operating System，HCOS）的部署所做的工作演变而来。 Apcera的博客证实，公司的目标和appc的目标是一致的：

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

CoreOS博客指出，红帽指派了一名工程师作为 appc的维护人员参与进来。除此之外，appc项目建立了管理政策，从谷歌和Twitter选出了几位新的、与CoreOS无关的社区成员。来自CoreOS的两位最初的规范开发人员， Brandon Philips 和 Jonathan Boulle ，也保留作为维护人员。

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

在四月份，VMware宣布对appc的支持，在 Photon项目中发行了rkt，这是VMware的轻量级Linux操作系统，使得rkt成为VMware的vSphere和vCloud Air客户的部署机制。CoreOS指出，VMware 重申了对appc的承诺，并正在与社区紧密合作来发展该规范。

InfoQ采访了 Jonathan Boulle ，CoreOS的项目技术负责人，询问了与CoreOS Fest上最近的这次宣布相关的问题。

InfoQ：Kubernetes中引入对rkt的支持，极大地有助于在此平台中支持多样化的容器生态系统。你们是否在与其它集群管理框架产品合作，比如Mesosphere的Marathon、Apache Aurora或者AWS的ECS，来增加rkt的支持？

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

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

InfoQ: 存储和网络在容器化的平台中仍然是个挑战。你觉得appc规范如何有助于解决这些问题？

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－－利用他们的专业知识和经验，回馈到规范中。

InfoQ：随着容器正在越来越成为在Linux服务器上的主流，我们看到其它市场，比如Windows服务器和物联网（IoT）平台，现在正在对容器化开放。你觉得appc或rkt在这些领域会有影响吗？

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

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

InfoQ：宣布更多公司支持appc规范，非常有助于确保这样一个社区项目的未来。你觉得未来会看到Docker公司正式加入支持者的行列吗？

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

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

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

InfoQ：Docker Github代码库上提交的‘Appc在docker引擎中作为一个运行库选项’的拉取请求（PR），没有产生太多的讨论（除了在相关的代码概念证明（POC，proof-of-concept）拉取请求上）。你对此感到惊讶吗？

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

InfoQ：一些开发人员在建议，容器的领域要进行标准化还是太早了吧。你对此有什么看法？

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

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

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

InfoQ：对appc规范或rkt何时能够达到v1，成为普遍可用（generally available），你是否能够提供任何指南？

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

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

CoreOS的博客在结尾处邀请新的公司参与appc社区，并鼓励开发人员加入 appc邮件列表和 Github 上的讨论来参与appc规范和rkt的实现。

查看英文原文： CoreOS App Container Spec Gains Support from Google, Apcera and Red Hat

感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群 CoreOS应用程序容器规范获得谷歌、Apcera和红帽的支持）。