火箭弹外弹道计算程序

这已经不是什么秘密了：在过去的一两年中，应用程序容器的兴趣和普及度激增。 尽管Docker一直是这一趋势的推动力，但也有其他竞争者。 其中也许最主要的是火箭。

要了解有关Rocket及其基础的应用程序容器规范的更多信息，我们赶上了Jonathan Boulle。 Boulle是CoreOS的工程师，他领导Rocket的开发，并围绕App Container规范进行了大量协调工作。 在CoreOS工作之前，Boulle曾在Twitter上从事过类似项目的工作，虽然从未见过这样的事情，但能够将一些想法和经验应用于他目前在Rocket上的工作。

Boulle在今年的南加州Linux Expo（SCALE 13X）上就Rocket和应用容器规范进行了演讲 。 在这次采访中，我们请乔纳森（Jonathan）告诉我们更多有关火箭，集装箱及其前进方向的信息。

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

首先，我将为您提供有关什么是容器的快速定义，然后我将解释为什么要回答这个问题有点棘手！

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

容器的另一个重要方面是，它们通常以某种方式受到限制，无法与外界（即主机操作系统）进行交互。 例如，一种常见的用例是对容器应用内存限制，这样，如果其中的应用程序超出某个限制，则不会影响运行容器的主机。

现在，“容器”一词的历史问题是它有点含糊不清，每个人的定义都有些微妙（有时是明显不同）。 例如，在Linux内核中，实际上没有容器这样的概念，当人们使用“容器”一词时，通常是用来描述诸如chroots，cgroups和命名空间之类的基础技术的任意组合。 这种含糊不清是创建App Container规范的主要动机之一：我们确实想详细描述什么是容器，并让广大社区能够将其作为参考。

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

什么是火箭？ 它与Docker有何不同？

Rocket是用于应用程序容器的新运行时，尤其是“应用程序容器规范”的实现，这是我们提议作为容器的开放且可互操作的标准。 Rocket的设计首先是为了简化，可组合性和安全性，尽管它处于开发的早期阶段，但最终针对具有严格安全性和生产要求的服务器环境。

与Docker的主要架构差异之一是Rocket仅以CLI工具“ rkt”的形式存在。 没有长时间运行的整体式守护程序或API。 相反，所有操作都是通过rkt的独立调用执行的。 这种设计意味着我们可以直接在rkt本身的进程树下运行应用程序容器，而不是由其他守护程序分叉它们。 这里真正重要的含义是，应用于rkt的任何隔离或流程管理都将应用于容器中的应用程序。 这使我们可以与init系统进行一流的集成。 例如，在systemd主机上，任何单元文件约束（例如内存限制）都将传递给rkt实际运行的应用程序。 并且当systemd取消rkt进程时，可以保证清理整个容器。

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

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

另一个重要的体系结构差异（可以追溯到规范本身的设计）是容器中的一流公民是一组应用程序，而不仅仅是一个应用程序。 Google的Kubernetes团队正是用这种模式来解释他们的pod的概念。 通过将基本可部署单元定义为一个组而不是单个应用程序，它使我们可以在单个Rocket容器中真正轻松地支持许多常见用例，因此用户不必担心在容器之间建立不同的链接等。向前。

为什么容器具有“应用容器规范”很重要？ 谁来决定该规格的外观？

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

在CoreOS，我们坚信开源，我们绝对希望规范成为社区拥有和驱动的东西。 在起草规范时，我们从Google，Mesosphere和Pivotal等公司的工程师那里寻求并获得了很多非常宝贵的意见。 自公开发布和发布以来，我们已经收到了来自这些开发人员和世界各地其他开发人员的数十份贡献。 这是一个高度协作的项目。 随着规范的稳定和更多实现的出现，我们将寻求围绕appc组织创建一个更正式的结构来指导其未来。

您是否认为开源社区围绕单一容器规范进行融合很重要吗？ 在这个领域，竞争是件好事吗？

在开源社区中，竞争绝对是一件大事。 它提供了许多新功能，并且可以防止工程师在开发软件时沾沾自喜。 但是，正如我之前所说的那样，整个社区都可以同意并建立的规范非常强大，因为它允许围绕便携式应用程序出现整个生态系统。 我们并不期望行业会在一夜之间融合，但是从应用程序容器规范的一开始就一直认为，我们希望并希望看到各种各样的替代实现。

我想在这里提一提的是，与现有的常见实现的互操作性对我们也很重要。 您可以肯定会在不久的将来看到一些有趣的集成。

告诉我们一些关于Rocket社区的信息。 谁在贡献代码，协作过程是什么样的？

火箭开发完全通过GitHub和邮件列表公开进行。 就贡献而言，我们在CoreOS外部有大约50个开发人员提交了补丁和改进（在某些情况下是真正的主要功能），这真是太好了。

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

火箭才几个月大。 您在未来的路线图中看到了什么？ 目前该项目的状态如何，事情发展的速度有多快？

该项目仍处于初期阶段，但开发工作进展Swift，我们对它的成熟程度感到非常满意。 Rocket已经完全具备了在基本配置中运行应用程序的能力，并且更高级的功能（例如，我们的网络插件系统）正在逐步完善，并将很快发布。

我们拥有许多关键要素，例如图像发现，签名验证以及基于文件的锁定框架，以协调多个Rocket实例。 在近期的路线图上，我们希望获得一些重要功能，例如更高效的磁盘文件存储，强大的图像索引以及对容器文件系统的overlayfs支持。

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

人们如何学习和参与Rocket？

我们希望有更多来自社区的人参与Rocket！ 最好的起点是GitHub存储库 ，我们在其中提供了有关如何开始使用Rocket的说明以及越来越多的文档。 我们还有一个专门针对Rocket的开放式邮件列表， 网址为： rocket-dev@googlegroups.com ，对于实时讨论，我们通常使用Freenode上的#coreos IRC室。

对于那些渴望开始进行黑客攻击的人，我鼓励他们在GitHub上查看“ Help Wanted ”标签中的问题，我们有许多问题，从简单的错误修复到我们希望获得帮助的更大功能。

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

翻译自: https://opensource.com/business/15/2/interview-jonathan-boulle-rocket

火箭弹外弹道计算程序