Rocket 和应用程序容器规范

这已不是秘密：在过去一两年中，人们对应用程序容器的兴趣和欢迎程度大幅 surge。虽然 Docker 一直是这一趋势的驱动因素之一，但也存在其他竞争者。其中最主要的也许是 Rocket。

为了更多地了解 Rocket 以及作为其基础的应用程序容器规范，我们采访了 Jonathan Boulle。Boulle 是 CoreOS 的一名工程师，他正在领导 Rocket 的开发，并围绕 App Container 规范进行大量的协调工作。在加入 CoreOS 之前，Boulle 曾在 Twitter 从事一个类似的项目，该项目从未真正面世，但他能够将一些想法和经验应用到他目前在 Rocket 上的工作。

Boulle 将在今年的南加州 Linux 展会 (SCALE 13X) 上就 Rocket 和应用程序容器规范进行演讲。在这次采访中，我们请 Jonathan 更多地谈谈 Rocket、容器以及它们的未来发展方向。

对于那些不熟悉这个主题的人，您如何解释什么是容器？为什么突然对容器作为传统虚拟化的替代方案产生了兴趣？

首先，我将给您我对容器的快速定义，然后我将解释为什么这是一个有点棘手的问题！

容器的基本思想是将应用程序打包成自包含的单元：容器不依赖于底层操作系统提供的任何库或工具，而是将应用程序的所有依赖项都包含在其中。在某种程度上，它类似于静态链接二进制文件的概念：容器中的软件是自包含的，运行时不需要任何其他东西。

容器的另一个重要方面是，它们通常在某种程度上被限制与外部世界（即主机操作系统）交互。例如，一个常见的用例是对容器应用内存限制，这样如果容器内的应用程序超过某个限制，它就不会影响容器运行所在的主机。

现在，关于术语“容器”的历史问题是，这是一个有点模糊的词，每个人都有略有不同（有时是显着不同）的定义。例如，在 Linux 内核中，实际上没有容器这样的概念，当人们使用这个词时，它通常用来描述底层技术的任意组合，如 chroots、cgroups 和命名空间。这种歧义是创建 App Container 规范的主要动机之一：我们真的希望详细地写下容器是什么，并让整个社区能够同意将其作为参考点。

容器最近受到如此多关注的原因在于效率和可用性。与传统虚拟化相比，容器更加轻量级：它们不会产生相同的性能损失，并且不需要部署或管理整个操作系统。但也许更重要的是，容器使开发人员可以非常轻松地在“无尘室”环境中快速迭代和开发，而无需启动虚拟机。并且由于容器具有可移植性和自包含性，因此它们可以与持续集成系统集成，并非常容易地部署到生产环境。这种简化的工作流程和更高水平的可移植性使得创建分布式、可靠、可重现的软件架构变得更加容易。

什么是 Rocket？它与 Docker 有何不同？

Rocket 是应用程序容器的新运行时，特别是它是“App Container 规范”的实现，我们正在提议将其作为容器的开放和可互操作的标准。Rocket 的设计首先考虑的是简单性、可组合性和安全性，虽然它还处于开发的早期阶段，但最终目标是用于具有严格安全性和生产要求的服务器环境。

与 Docker 的主要架构差异之一是 Rocket 仅以 CLI 工具 `rkt` 的形式存在。没有长期运行的单体守护程序或 API；相反，所有操作都通过独立调用 rkt 执行。这种设计意味着我们可以直接在 rkt 自身的进程树下运行应用程序容器，而不是由不同的守护程序 fork 它们。这里真正重要的含义是，应用于 rkt 的任何隔离或进程管理都应用于容器中的应用程序。这为我们提供了与 init 系统的第一类集成；例如，在 systemd 主机上，任何单元文件约束（如内存限制）都会传递应用于 rkt 实际运行的应用程序。当 systemd 关闭 rkt 进程时，它保证清理整个容器。

此模型解锁的另一个关键能力是，我们可以提供简单的就地升级，而不会中断现有容器：没有 Rocket 守护程序需要重启，因此可以在不需要杀死正在运行的容器的情况下执行升级。当然，即使没有守护程序，仍然需要跟踪一些状态，但我们利用文件系统和进程树，这意味着我们可以依靠内核来为我们跟踪和强制执行此操作。例如，我们使用容器目录的文件锁定来保证可以同时多次运行 rkt，而不同的调用不会互相干扰。

最后，CLI 模型的另一个重要好处是，我们可以开始梳理不同操作所需的权限，而不是通过以超级用户身份运行的守护程序运行所有操作。

另一个重要的架构差异——这可以追溯到规范本身的设计——是容器中的第一类公民是一组应用程序，而不仅仅是一个应用程序的想法。这是 Google 的 Kubernetes 团队在他们的 pod 概念中出色解释的模式。通过将基本可部署单元定义为组而不是单个应用程序，它使我们能够在单个 Rocket 容器中非常轻松地支持许多常见的用例，因此用户不必担心在容器之间设置不同的链接等等。

为什么容器拥有“App Container 规范”很重要？谁来决定该规范的外观？

拥有规范真正重要的事情之一是，到目前为止，还没有对容器到底是什么的标准化和不可知定义。不同的容器运行时（如 Docker 和 LXC）都有自己的想法和实现，从某种意义上说，这些是事实上的标准，但从未有过从头开始设计或以开放方式正式描述的东西。这意味着不仅这些不同的系统很难协同工作，而且任何针对现有工具构建的人都面临着他们的代码在上游软件更改时随时中断的风险。通过将容器规范与实现分离，以规范形式编纂它，并选择正确的抽象，我们可以创建真正可移植、可组合和可互操作的东西，这非常强大。

在 CoreOS，我们是开源的坚定信徒，我们绝对希望该规范成为社区拥有和驱动的东西。在首次制定规范时，我们寻求并收到了来自 Google、Mesosphere 和 Pivotal 等公司的工程师的大量有价值的意见。自从公开宣布和发布它以来，我们收到了来自这些公司和世界各地其他开发人员的数十个贡献。这是一个高度协作的项目。随着规范的稳定和更多实现的出现，我们将考虑围绕 appc 组织创建一个更正式的结构来指导其未来发展。

您认为开源社区围绕容器的单一规范达成一致是否重要？竞争在这个领域是好事吗？

竞争绝对是开源社区中的一件好事；它推动了许多新功能，并可以防止工程师在开发软件时变得自满。但正如我之前所说，社区可以广泛同意并围绕其构建的规范非常强大，因为它允许围绕可移植应用程序出现整个生态系统。我们不期望行业在一夜之间趋同，但从应用程序容器规范的最初开始，我们最重视的是我们希望并希望看到各种不同的实现。

我想在这里提及的另一件事是，与现有常见实现的互操作性对我们来说也非常重要。您绝对可以期待在不久的将来看到一些有趣的集成。

请您谈谈 Rocket 社区。谁在贡献代码，协作过程是怎样的？

Rocket 的开发完全是公开进行的，通过 GitHub 和邮件列表。在贡献方面，我们有大约五十名 CoreOS 外部的开发人员提交了补丁和改进——在某些情况下是真正重要的功能——这非常令人高兴。

我们鼓励人们使用 GitHub 问题来跟踪大多数事情，我们在那里对新功能和更改进行了许多健康的讨论。一般的流程是，某人将提交功能请求或补丁，来自社区的其他感兴趣的各方将进行评论并参与讨论，然后我们将就我们是否想要做这件事达成共识。由于 Rocket 还是一个非常年轻的项目，到目前为止这种情况发生得非常快。对于较大的提案，我们发现 Google Docs 上的评论系统在跟踪反馈和讨论方面提供了更好的体验，因此在这种情况下，我们将使用 GitHub 和邮件列表来宣布该文档，然后向所有人开放以发布评论。

Rocket 只有几个月大；您如何看待未来的路线图？该项目现在的状态如何，成熟速度有多快？

该项目仍处于非常早期的阶段，但开发进展迅速，我们对它的成熟度感到非常满意。Rocket 已经完全能够在基本配置中运行应用程序，更高级的功能（例如，我们的网络插件系统）正在顺利成型，并将很快在版本中提供。

我们已经到位了许多关键部分，例如镜像发现、签名验证和用于协调 Rocket 多个实例的基于文件的锁定框架。在近期路线图上，我们期望实现一些重要功能，例如更高效的磁盘文件存储、镜像的强大索引以及对容器文件系统的 overlayfs 支持。

在这些特定的技术功能之外，目前指导 Rocket 开发的关键因素之一是 appc 规范本身的演变。随着它向稳定版本发展，我们将继续定期更新 Rocket，以使其与规范的最新更改保持同步。

人们如何了解更多信息并参与 Rocket？

我们非常欢迎更多来自社区的人参与 Rocket！最好的起点是 GitHub 仓库，我们在那里提供了有关如何开始使用 Rocket 以及不断增长的文档池的说明。我们还有一个专门用于 Rocket 的开放邮件列表：rocket-dev@googlegroups.com，对于实时讨论，我们通常使用 Freenode 上的 #coreos IRC 房间。

对于那些渴望开始 hacking 的人，我鼓励他们查看 GitHub 上带有“Help Wanted”标签的问题，我们在那里有各种各样的问题，从简单的错误修复到我们希望得到帮助的更大的功能。

对于那些有兴趣阅读更多关于我们创建 Rocket 和 appc 规范的原因的背景信息的人，他们应该查看初始博客文章。