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 读者交流群）。