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

作者 张磊

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

谁也没料到的是，这次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热潮，此刻确实需要降温。

作者介绍

张磊，Hyper项目成员，Kubernetes项目Project Manager和Feature Maintainer, CNCF成员。