三年后，咱们从 Docker 转到了 RKT

在 Swarm 被归入 Docker 1.12后，Swarm 与 K8S 之争日趋白热化。本文做者 Adriaan de Jonge 身为 Xebia CTO ，专精 DevOps 及持续交付，曾为 Docker 摇旗呐喊三年的老司机，现在开始易帜。

如今即便是最酷的产品也绑定于某个特定供应商。无论在过去的三年里，我曾多么热衷 Docker，可是如今，绑定的供应商开始动摇 Docker 在我心中的地位了。而目前他们二者之间的竞争还在持续。又或许在这个过程当中会出现一个更好的选择也说不定。这篇文章就是带领你们来了解一下 Core OS 的 rkt（读音按照“rock－it”来），以及告诉你为何从如今开始要了解 rkt。

Docker 怎么了？

若是你跟我经历类似，你可能由于对 Docker 充满热情而被它的一些缺点蒙蔽了眼睛。不要误解我，我并非说 Docker 很差。个人意思是它并无那么完美。因此接下来让咱们来看一下它的一些不足之处吧。

Docker 愈来愈像之前的 Microsoft

一旦一家公司意识到它有着本身的垄断权，他们就会开始作出垄断行为。一如微软曾经试图经过在 windows 中安装 Internet Explorer 来排挤 Netscape，如今 Docker 正在尝试将 Swarm 融入到 DockerCore，以此来打击 Kubernetes，Mesos，Marathon 和 Nomad。

Docker 确实有简化 Swarm，使它轻松被广大 Docker 用户接受的优势。如同微软确确实实提高了 Internet Explorer6.0的性能。MSIE6浏览器突出了微软的优点，因此他们在5年内都没有继续开发了。

想象一下 Docker 跟 Swarm 结合的结果是什么……想象一下你的下一个任务就是移动到 Docker：当须要选择一个最好的调整程序时，在你选择 Kubernetes，Mesos／Marathon，Nomad 以前，你首先要理清楚的就是 Swarm 的不足之处是在哪里。已经有了 Swarm，那么为何在这个基础上还要安装其余的调度程序呢？

我但愿 Docker 可以提高 Swarm 的性能，在修改这一点上，但愿 Docker 作得比微软（修改 MISE）要好。可是即便是如今，Kubernetes 在不少方面也都是领先于 Swarm 的。随着 Kubernetes 的持续开发，Swarm 已经远远落在后面。虽然 Docker 可以让人轻松使用调度程序，可是在我看来，他们仍是应该跟 Docker 核心分开。

“Docker 的架构从基础上来看就是有瑕疵的”

Docker 的核心就是 Daemon 程序，这个程序是 Docker 开始运行的起点。Docker 可执行文件仅仅只是一个 REST 代理，这个代理要求发请求给 Docker daemon 来完成它的工做。Docker 的评论家指出，这很不符合 Linux 的方式。

它的痛点在于你是否使用相似 systemd 这样的初始化系统。由于 systemd 并非针对 Docker 设计的，因此当你尝试开启一个 Docker 程序的时候，你其实也就是开启了一个 Docker 代理程序，而这个代理程序向 Docker daemon 请求开启真正的 Docker 容器。在这里仍是有一个风险的，就是当 Docker 容器还在运行的时候，Docker 代理运行失败了。在这样的状况下，systemd 得出结论，程序已经中止，而且重启 Docker 代理——因而建立第二个容器（是的，你仍是能够继续处理工做，可是已是可有可无的了）。

大概一年以前，我把 systemd 当成是一个简单的 Docker 调整程序来调查。我遇到了一样的危机，或者说将 Docker 和 systemd 结合的问题。那时候，我以为这些是 systemd 的缘由，而不是 Docker 的缺点。我那时候还想，会不会 systemd 并非针对“Docker 本地”来设计的。

如今，我才了解到，可能 Docker 才是那些问题的症结所在，而不是 systemd 的问题。就像上文中提到的，Docker 并不符合 Linux 的风格，而也正由于如此，Linux 工具跟 Docker 也协做得不是很好。因此是谁错了呢？是新来的 Docker，仍是已经存在了多年的 Linux 工具呢？CoreOS 的 CEO，Alex Polvi说：“Docker 的架构从基础上就有瑕疵。”

Docker 建立程序，陷在了第二个阶段

Docker 最好的功能之一就是 Dockerfiles 的引入，你能够在构建 Docker 镜像时保持版本控制。这里惟一的问题是在 Docker 的路标中 Dockerfile 语法冻结很长时间了。这就意味着在过去的一年半以来 Dockerfile 格式并无依据社区的良好建议而进化。

固然，在某种程度上，咱们须要一个稳定的格式，可是只有当格式彻底成熟的时候。在这里举个例子，就是 Dockerfile 缺少的地方，考虑到 Kelsey Hightower 在他博客《12 Fractured Apps》中提到的：“记住，咱们要运送artifact，而不是编译环境。”

事实就是，Dockerfile 格式并不能很好地支持这个区别。考虑到要构建一个可执行的 Golang：可执行的结果可能只有两百万字节大小，可是建立的环境有几百兆字节。固然，你也能够在本地系统上构建镜像。你没法利用 Docker Hub 中的自动化构建环境经过一个简单的 Dockerfile 优雅的构建出一个小的 Golang 镜像。社区有个关于扩展 Dockerfile 格式的提议就能很好的支持上述原理，可是因为 Dockerfile 格式的冻结该提议也被搁置了好几年。

那么，rkt 是如何缓解这个情况的？

简而言之，rkt 如今给 Docker 提供了更好的解决办法。它拥有一套更加 Linux 的架构。这个强劲的对手会保持本身的垄断做风。

具体一点的答案就是：2014年年末，Core OS 宣布，这个有竞争力的容器平台 Rocket（后来简写并更名成 rkt）的诞生。虽然 rkt 在发布以后最初几周里获得了很高的关注度，可是后来却销声匿迹了。Core OS 仍是将 rkt 做为 Docker 的可替代工具来开发，后来在2016年2月 rkt1.0版本发布的时候才回归大众视野。

如今 Docker 宣布在 Docker Engine1.12中已经包含了 Swarm，那么是时候正视 rkt，让它做为 Docker 的可执行方案了。那在将来它会替代 Docker 吗？从 Docker 切换到 rkt 难度大吗？

让咱们来看一看 rkt 寻找答案吧。

rkt 可以运行 Docker 镜像

假设如今你想要用 rkt 来替代你的 staging 以及产品系统，同时又想让你全部的开发系统都继续运行......在这个案例中，你能够只在你的运行系统上将 Docker 替换成 rkt。但严格来讲，这并非一个随随便便的替换。毕竟，架构是不同的——可是咱们会努力往同样的方向发展的。另外一方面，为了在 rkt 上运行 Docker 容器而去学习新的命令行指令也不会太难。
在你最爱的云提供商上打开 Core OS 实例，并打出如下代码：

或者用你最爱的 Docker 镜像来替代 nginx。在底层，rkt 将 Docker 转换到ApplicationContainer（appc）格式。

这也就意味着你不须要 Docker 来运行 Docker 镜像了。并且也意味着你能够从新使用 Docker 建立的东西，在这个过程当中不须要忍受迁移带来的伤痛——而不是学习 rkt 的命令行语法。

让咱们来一睹命令行的单个部分：

若是你没有忽略这部分，那么rkt就会拒绝启动你的镜像，由于它找不到签名（.asc file）来确认 Docker 镜像的完整性。rkt 默认设置下是安全建立的。在这个例子中，这也就意味着你能够经过提供合适的签名来省去一些命令的输入。

就好比在 Docker 中，你须要明确地暴露端口到外部。不像 Docker，rkt 端口已经被命名，而不是标记数字。若是这是一个原生的 rkt 镜像（或者须要精确的appc），那么它读起来极可能是这样的：

然而，既然 Docker 没有命名的端口，那么被暴露的端口就会被自动命名为<number>-<protocol>。这也就意味着，若是你只能显示暴露端口的话，就使用 Dockerfile 中的 EXPOSE 关键字：

镜像指望存储在默认的 Docker 仓库中（Docker Hub）。除了这个例子，还有个更长的 URL 指向另外一个 Docker 仓库（docker://）或者包含镜像的一般的 web 网站（https://），可是以后你就再也不运行 Docker 镜像了。

Rkt 有着更加简单的架构

在 rkt 中是没有 daemon 进程的。Rkt 命令行工具作了全部的工做。来看从CoreOS 网页借鉴的图片：

跟 Docker 不一样，若是你使用 systemd 来启动 rkt容器，你实际上就是在监控容器进程，而不是监控代理程序，而后由代理程序链接到 daemon，并由 daemon（直接或者间接——依赖于你的 Docker 版本）来启动容器。

另外一方面，你不能这么写：

像 Docker 代理同样 daemon 化进程。并且必需要运行一个初始系统来 daemonize 进程。好比，你能够这样运行：

一样，你没法从远程机器（好比 Docker 代理）运行 rkt 命令行。再有，你也能够将它做为安全功能考虑。

Rkt 为镜像听从开放标准

如今，rkt 容许你使用 Application Container（appc）或者 Docker 镜像。在不远的未来，Open Container Initiative（OCI）格式将会被加入，咱们会朝那个方向走的。

容器镜像拥有开放标准的好处就是，它容许开源社区提供多种建立镜像的方法，不只仅局限于 Dockerfile 格式。

构建 appc 镜像的默认方式就是使用命令行工具，叫作 acbuild。说实话，喜欢 acbuild，仍是喜欢 Dockerfile 格式，这真的只是我的口味问题。
好处就在于它天生就跟 Linux 原则距离更近。

而最大的好处就是开放格式容许可替代的构建机制。好比，考虑到全能建立工具 dgr 或者 Golang 指定建立工具 goaci。

一旦 OCI 格式可用，就会有更多可能，可是如今，咱们仍是须要等待。

Rkt：咱们到达目的地了吗？

若是你如今就想要开始使用 rkt，那么你在使用道路上会有一些磕绊。虽然说你能够在磕磕绊绊之中找到方向，可是不得不认可的是，在我写这篇文章的时候（也就是如今），说 rkt 一切都已经准备稳当还为时过早。不过，我相信，只是时间问题。

OCI 镜像格式尚未准备好

就像在上文中提到过的那样，rkt 支持 Docker 镜像格式，并且跟 Docker 仓库互相沟通联系。若是你可以坚持使用 Docker 镜像格式，那么相信它，它会运行得很好。

可是，若是你是个吹毛求疵的人——像我似的——你就没办法容忍在使用 Docker 的时候，你还没法使用命名的端口。因此，你就会想要使用 appc 容器。appc 容器是能够自由使用的。

可是你要怎么上传 appc 容器给 Core OS 解决方案到 Docker Hub——quay.io？我本身是尚未找到这样的方法。

关于 appc 格式最好的一点就是，它并非跟特定的 Docker 仓库相联系。反而，你能够在普通 http 服务器上，或者是在本地文件系统宿主镜像。你能够丰富包含元标签的 HTML 文件的原数据。

一旦 OCI 镜像格式达到，rkt 才有可能真正 take off，变得足够成熟，准备足够充分来被接受，做为每一个人心中的标准——包括 Docker。

Nomad&Kubernetes 尚未彻底成熟

为了在产品中运行容器，在某种程度上，你须要一个调度程序来控制运行什么程序，在哪里运行。目前，Kubernetes 和 Nomad 都支持 rkt。可是这种支持并无你们指望得那样成熟。

Kubernetes 支持 rkt 是从积极开发的情况下来讲的。它有最小文档以及一系列已经知道了解的问题。Nomad 支持标记试验，可是不支持动态端口。

对于其它平台来讲就不那么轻便

好在 rkt 不只仅支持 CoreOS。你能够在多个平台上，好比分布式 Linux，Debian，Ubuntu 以及 Fedora 上安装 rkt。

若是你想在你的 Apple／Windows 开发机上运行 rkt，你固然能够在像 virtualBox 这样的虚拟层运行。可是，这些设备没有 Docker 的工具盒那么好用——特别是最新的 Docker Mac／Windows 测试版，这也就给了你一种 native 的感受。要认可的是，这可能就是 rkt 架构上的缺点，在这点上，可执行的 rkt 已经作了全部的工做，而不仅是做为一个 REST 代理。

若是你想要在非 Linux 机器上开发，最好的办法就是仍然在本地用 Docker 镜像进行处理，而且在你转到 staging 和生产的时候，要将这些转化为 appc 镜像。

结论

虽然这么说还很早，可是 rkt 如今已经变成 Docker 的一个可执行方案。若是你不须要 Kubernetes，Nomad 的动态功能，以及更多像 systemd，fleet 这样的静态选项，来知足你的调度准则，那么你如今就能够将你的 staging 和产品服务器转移到 rkt 了。

相信再有多一点的时间，Docker 和其它容器平台间会有真正的互操做性，以 OCI 镜像的形式出现。同时，容许 Kubernetes 和 Nomad 支持 rkt 的发展，而后 Docker 会跟 rkt 容器平台会同样可交换。

那如今有必要摒弃 Docker 吗？不，没有必要。除了这篇文章中提到的一些 Docker 的缺点，Docker 仍是个有着不少开发工具，调度程序，编排的巨大生态系统创新平台。重要的是，咱们要有足够多的选项。如今 Docker 有不少的竞争对手来保持清醒。

原文连接保护知识产权，转载联系咱们哦。