“从此社区再无 Docker？” 那 “Moby” 又是什么？-InfoQ

DockerCon 上重点发布的“Moby”，在国内技术圈引起了不小的震动。厂商们普遍为 Docker 公司释放 Moby 项目拍手称赞，一线技术圈（GitHub，HN）却掀起了一阵 “口诛笔伐” 的小波澜。容器圈内一位多年的 Docker 项目贡献者甚至直接感慨：“从此社区再无 Docker！”这件事，究竟该如何解读与看待？

背景介绍

DockerCon 2017 在四月如期举行。近两年随着 Docker 公司逐渐在自己的商业产品上不断加码，现在的 DockerCon 类似于一场 “客户 + 产品 + 战略” 的大型发布会，也让全世界的后端开发者们感受到了容器技术 “当家花旦” 的独特魅力。

谁也没料到的是，这次 DockerCon 上重点发布的 “Moby”，却在国内这个以往不太跟国际接轨的圈子里引起了不小的震动。有趣的是，在厂商们普遍为 Docker 公司释放 Moby 项目拍手称赞的同时，一线技术圈（GitHub，HN）里却掀起了一阵 “口诛笔伐” 的小波澜。知乎该话题下的一篇高赞匿名回答 ( 倒不如说是吐槽）：

https://www.zhihu.com/question/58805021/answer/159490433

更是一时间取代了 DockerCon 本身成为了技术圈里争相讨论热点。如此矛盾的表现，为这个本来就不太明朗的商业事件更增添了难以理解的色彩。

到底发生了什么？

“Docker，还是 Moby？”

一向善于创造 fancy 的新名词的 Docker 公司，这还是头一次因为一个新名字陷入尴尬的局面。而这次“危机”的源头，则是 Docker 公司在并未对外释放明显信号的情况下，直接将 Github 上原隶属于 Docker 组织的 Docker 项目，直接 transfer 到了一个新的、名叫 Moby 的组织下，并将其重命名为 Moby 项目。这此并无征兆的突然“改名”和“移交”，正是本次 DockerCon 2017 上宣布的唯一一个大新闻。对此，容器圈内一位多年的 Docker 项目贡献者直接感慨：“从此社区再无 Docker！”

说的一点没错。

究竟如何解读？

实际上，知乎回答的总结部分已经一针见血了：

“Docker 公司直接把原 Docker 项目改名成了 Moby，是为了将之前数年里构建出来的庞大的粉丝团体和 Google 搜索内容（Google search footprint）全部转移到 Docker 公司的商业产品上。”

在开源项目的运营是一个系统工程，但是整个过程中确有这么三个入口是维护者需要苦心经营的重中之重：

Google 搜索结果
Stackoverflow 上的问答内容
Google Group 的讨论话题

一个开源项目要想成功，一个重要的手段是在目标受众群体中赢得广泛的用户基础，然后以此为基础构建外围生态。说的更现实一点，就是必须要有热度和知名度。只有不断被受众群体提及并且关注的开源项目才有机会生存下去。这个现实也是开源圈子里向来”只认第一，不认第二“的一个重要原因。

Docker 项目可以说是近几年最成功的后端开源项目之一，更难能可贵的是，Docker 项目的成功并非像 Tensorflow、Kubernetes 这种含着金钥匙出生的名门之秀，也非像 Etcd 这种定位于核心依赖并且容易被纳入已有体系的独立模块。Docker 项目本身是带着颠覆性的，是要求你推倒重来的（这不同于 Etcd）。但它本身又没有什么黑科技成分，没有太高的进入门槛（这又不同于 TF，k8s），它全部构建于现有的操作系统技术之上，却几乎单靠着 Idea 本身就取得了巨大的成功。这种项目，短时间内不可能再出现下一个了，因为它的出现，几乎就意味着一个新产业的诞生。

我们一般能够从 star 数估计出一个开源项目背后的生态，但是 Docker 项目背后的生态和群体规模，恐怕要比 4 万个 star 所能代表的意义要大得多。

成千上万的用户，支撑起国内外无数家创业公司的庞大产业，数十亿美元的风险资本，庞大的关联产业群体，甚至说它重塑了云计算市场也不为过。 “Docker” 这个 Google footprint 背后的价值，委实难以估量。

对于 “Docker 到 Moby” 的转变，业界可谓众说纷纭，但最为困扰用户和开发者的，无外乎两个问题：

如果是为了更好的模块化 Docker 项目（所谓的“乐高”式的架构），那么为什么不能保留 Docker 项目的名字，然后再拆分？
如果是为了更好的区分 “project 和 product” ，那么为什么不能给 Docker 公司的商业产品取个更好听的企业版名字（比如 Moby），而保留 Docker 作为一个独立的开源项目？

最后的结果是令人遗憾的，甚至都没在社区进行公开讨论的余地。

所以，无论 Solomon 如何辩解，无论是手绘架构图还是连发 Hacknews，这一次 “Docker 到 Moby” 的转变过程，其背后透露出来的用意无比清晰而坚定：

“从今往后，Docker 关键字的价值只属于 Docker 公司。”

这种略显霸道的做法，正是一线开发者层面矛盾被激发的源头。

但这冰冻三尺，又非一日之寒。

早在 Docker 项目刚受到广泛关注不久，就已经有很多意见指出 Docker 这个名字既是公司名字，又是开源项目的名字，而且很快又成了公司商业产品的名字，这本身就是很大的隐患。但 Docker 公司并没有采取什么措施，反而更加关注和遏制任何第三方试图滥用 Docker 关键字的苗头。

Docker 公司有意无意之间制造的这个模糊地带，在 Docker 项目高速发展的两年里，将开源社区用心经营出来的庞大受众和用户群体，同公司未来商业产品的影响力和目标客户通过 “Docker” 关键字成功的统一起来。然后，在 “Docker 到 Moby” 这个原本可以用来修正这个错误的时间点上，Docker 公司又毫无征兆地、以迅雷不及掩耳之势完成了 Docker 项目的重命名。至此，“社区再无 Docker”，就成了这个无比成功的项目最后的感慨。这也是 Github 上和 HN 上的开发者感觉被冒犯的主要原因。

我们无法判断这是不是 Solomon 一个人的决定（笔者倾向于这应该是董事会共同完成的战略决断，甚至有可能有传说中 VC 方面的压力），但这件事情本身的发展过程，却同“善意的独裁者”这一形象不谋而合。没有投票，没有征询，没有公开的文档和章程来遵守，Docker 这个开源项目从诞生到“消失”，遵循着的都是不断颠覆人们预设的决定。我们甚至很难被说服 Docker 是一个真正的开源项目。有时候，我们觉得它更像一个商业产品的特定阶段，甚至，还带有几分传奇色彩，故意让我们看不清，摸不透：

“它崛起，它辉煌，它使命完成，它消逝不见”。

我们还有 Moby

困惑和焦虑，成为了 DockerCon 之后容器圈里的普遍情绪，尤其我们国内的 Docker 圈子比国外热度更高，产业也大，随之而来的失望也更大。像往日熙熙攘攘的容器技术讨论群里，冷不丁有人问一句“Docker 改名了，我们怎么办？”，实在难有几个靠谱的回应。事实上，我们自己的开源项目里也 vendor 了“github.com/docker/docker”。但是当讨论到某个需要修改的 Docker 代码时，我们也很困惑：谁知道我们要改的部分将来会拆到哪里去呢？是 Moby 下面，还是 Docker 下面？没人知道。

不过，至少有一点是可以肯定的，现在的 Moby 项目，依然会扮演着 Docker 容器圈里的重要角色。拆分之后，Moby 项目的独立性和健壮性也能有更好的保证，社区里的开发者和维护者还可以专注于自己熟悉的模块，而不是像现在一样拥挤在一个 Docker 项目上不可开交。

更为重要的是，厂商和一线开发者，对 “Docker 到 Moby 的转换” 可以说是完全不同的感受。对于 Google，CoreOS，RedHat，Mesos 等玩家来说，一个拆分后的、不隶属于 Docker 公司的开源项目，明显增加了更多合作而非竞争的机会。就拿 Google 来说，作为以往很容易被当靶子的一方，动不动就 “碾压 Kubernetes” 的拙劣对比估计很难再现了，一个真正开放的社区，在公开场合对同类项目的宽容、友善和协作才是主流基调。

事实上，Moby 开源项目今后的路线，在工业界已有范例，比如 Cloud Foundry 项目。Pivotal Cloud Foundry（PCF）作为一款 PaaS 商业产品，在全球范围内已经取得了巨大的成功，世界 500 强三分之二已经成为了 P 家的优质客户。但如果好奇的话，你会发现 GitHub 上并没有一个叫 CloudFoundry 的项目，而是以多个功能模块的方式散布在 cloudfoundry 组织下面，比如 UAA，GoRouter 等等。然后，开源社区用户可以通过一个叫 cf-release 的项目编译出来一套完整的社区版 CloudFoundry 供自己部署和使用。

Docker 公司目前的处理方法也是类似的。Docker 公司旗下两款产品分别是 Docker-CE（社区免费版）和 Docker-EE（企业收费版），它们都必须从 docker.com 官网下载下来使用（这是区分项目和产品的一个重要方式）。你并不会找到有一个开源项目叫 Docker-CE，但是你可以使用 Moby 组织下面的各个项目自己编译一个跟 Docker-CE 功能一样的软件出来。不过，估计少有人会这么做吧。大多数人应该还是图个方便会下载使用 Docker-CE，这也可以说是 Docker 公司的一个小手段：你都用了 CE 了，试一下 EE 又何妨呢。

LinuxKit

在 Moby 体系中，还有一个项目也值得关注，那就是 LinuxKit。细心的人可能已经发现了，LinuxKit 的前生是 https://github.com/docker/moby 项目（Docker 公司这玩儿名字是有多溜）。实际上，你如果用过 Docker for Win 或者 for Mac 的话，就知道在这种非 Linux OS 场景下，Docker 其实是启动了一个叫 MobyLinuxVM 的虚拟机来跑 Docker 容器的，为了能够让这个额外的 VM 层足够轻量级，内核裁剪和定制的工作就必不可少，这正是 LinuxKit 项目的来源。

比较有意思的是，DockerCon 上对 LinuxKit 的宣传都是在“安全”两个字上。这难免有抓眼球的嫌疑，定制宿主操作系统确实能够降低宿主机的被攻击面，但这并不改变容器本身在多租户环境中隔离性和共享内核的问题本质。这种推广方式也确实一度引起了国内一些用户的误解。不过，在使用了精简 OS 之后，用户在云上启动宿主机的时间就会大大减少，这的确是实实在在的好处。

那么究竟应该怎么解读 LinuxKit 呢？

首先需要明确的是：LinuxKit 本身并不是一个精简操作系统，它是用来编译出可运行的精简操作系统镜像（包括 kernel，disk.img， BIOS.iso 等）的工具，这一点区别，国内有些介绍文章也不经意混淆了。

其次是它的使用方式：用户首先需要使用 LinuxKit 工具来制作一个精简操作系统，然后在 IaaS 上或者裸机上使用 KVM 等来使用这个系统启动一个虚拟机来把这个操作系统运行起来。

需要注意的是，在制作的过程中，用户希望启动的 Docker 镜像也是要打包进去的。这样虚拟机启动后就会使用事先打包进的 Docker 镜像来启动容器进程，这个过程由内置 containerd 和 runc 来完成。

所以，这个通过 LinuxKit 打包出来的 OS 镜像确实具备了“可移植性”，但实际上还是要借助虚拟机来运行在 Mac 上或者 Windows 上等。这其实跟 CoreOS 等各种各样的专门用来跑容器 OS distro 区别不大。

另外，通过 LinuxKit 生成的这个可运行 OS 镜像，同时打包了操作系统和待运行的应用，这听起来是不是有点熟悉？没错。LinuxKit 正是 Unikernels 团队的作品，可以毫不隐晦的说，LinuxKit 实际上是一种 Unikernels 概念的更大众化的实现。毕竟，相比起徒手制作 Unikernels 镜像的过程，使用 LinuxKit 工具就要轻松多了。当然，这也意味着 LinuxKit 比 Unikernels 还是要重的，在实际测试中无论在资源使用上，还是启动速度上两者都有明显差距。

总结成一句话：LinuxKit 所定义的是一种 Unikernels 风格的、专门为运行容器任务而定制的 OS distro。

既然还是 OS distro，那么它的场景跟 CoreOS、RancherOS、RedHat Atomic 也是类似的。我也相信 Docker 用户应该没兴趣在裸机上大规模使用 LinuxKit，虽然 “使用 KVM 启动一个虚拟机” 这项工作被 LinuxKit 接管了，但接下来 “徒手” 进行虚拟化管理的工作能胜任的人恐怕就不多了。

但是在 LinuxKit 正在发力的公有云领域，OS distro 确实很有发挥空间。在这里，用户并不需要关系下面的虚拟机部分，就比如已经支持的 GCE 吧，用户只需往 GCE 上传自己的 build 出来的 LinuxKit OS 镜像，就可以在云上启动一个虚拟机来运行它，而打包进去的容器也随之启动了。这就实现了宿主机层面的一致性，也是在解决了 “这份代码在我机器上是可以跑” 的问题之后，“这个 Docker 镜像在我的机器上是可以跑” 这个新生问题的也终于得到了缓解。

当然，既然是 OS distro，你也可以在这个 OS 镜像中打包 Kubernetes binary，或者 swarmd，这样就相当于直接拿这些机器当宿主机在 GCE 上来搭一个容器云了。

不过话说回来，任何一种 OS distro 的目的之一，都是要制造 Vendor Lock，LinuxKit 也不例外。对于公有云提供商来说，这不是个友善的信号。想象一下，将来某一天 AWS 上的容器用户都不使用 AMI，而是使用 LinuxKit 镜像来启动虚拟机来跑容器了，那就真尴尬了。所以，如果真说 “降维打击”（事实上，我认为这个词开始被滥用了，只有它的原创者 Frank Yu 的精彩演讲里形容 Docker 和 PaaS 的关系才是最形象的一次比喻），LinuxKit “打击” 的是所有在操作系统层面试图针对容器做文章（包括 distro，安全补丁，精简内核等等）的玩家，这个覆盖面可不小。各家公有云，RedHat，CoreOS，Rancher 等大小公司恐怕都在其中。从这个角度来看，LinuxKit 的推广难度，可想而知。

最后提一句，LinuxKit 是自己一个单独的 org，不属于 Moby，也不属于 Docker，不绑定 SwarmKit，不内置 Docker Engine，其雄心壮志确实略见一斑。正如一位 Kubernetes 项目贡献者的评论所说的那样：这家伙不做 Unikernel 了，改做 Universal Kernel 了。

写在最后

当我们静下来重新审视 DockerCon 的这几项内容，不难发现，大多数容器用户实际上并无需过分纠结 Docker 或者 Moby。免费的 Docker-CE 会一直存在，Moby 开源社区依然会活跃，而且模块化后，要 hack 还变容易了，何乐而不为？

更何况，绝大多数用户都应该是在使用诸如 Kubernetes，DC/OS，SwarmKit 等上层编排工具的，在 containerd 都已经归属 CNCF 的今天，下层 runtime 的风吹草动实在不应该浪费大家时间去做过多思考。我相信，无论是原 Docker 项目的开发者，还是是心有不甘的匿名用户，最终还是希望能安安静静的写代码，“Docker 还是 Moby” 的讨论其实并没有太大意义。

唯一值得我们铭记的是，无论是过去还是现在，开源社区都并非 “世外桃源” 般的净土，它是现实商业市场在技术领域的延伸，它正在迅速地吞噬着现代软件世界，改变着我们的竞争规则。这里既有激烈的厂商斗争，也有友善的跨国协作，更有 Docker 公司这样的模式创新者来不断颠覆我们的思想。

作为身处其中的技术人员，唯有时刻保持对技术心存敬畏，对客观事实冷静思考，不盲从，不热捧，方才能有更坚实的立足之地。就如我们一度难以抑制的 Docker 热潮，此刻确实需要降温。