小鲸鱼大事记 | Docker诞生历程之群雄并起

做者：张磊

来源： 极客时间《深刻剖析Kubernetes》

在上一篇文章中，我剖析了Docker项目迅速走红背后的技术与非技术缘由，也介绍了Docker公司开启平台化战略的野心。但是，Docker公司为何在Docker项目已经取得巨大成功以后，却执意要从新走回那条已经让无数先驱们尘沙折戟的PaaS之路呢？

实际上，Docker项目一日千里的发展势头，一直伴随着公司管理层和股东们的阵阵担心。他们内心明白，虽然Docker项目备受追捧，但用户们最终要部署的，仍是他们的网站、服务、数据库，甚至是云计算业务。

这就意味着，只有那些可以为用户提供平台层能力的工具，才会真正成为开发者们关心和愿意付费的产品。而Docker项目这样一个只能用来建立和启停容器的小工具，最终只能充当这些平台项目的“幕后英雄”。

而谈到Docker项目的定位问题，就不得不说说Docker公司的老朋友和老对手CoreOS了。

CoreOS是一个基础设施领域创业公司。 它的核心产品是一个定制化的操做系统，用户能够按照分布式集群的方式，管理全部安装了这个操做系统的节点。从而，用户在集群里部署和管理应用就像使用单机同样方便了。

Docker项目发布后，CoreOS公司很快就认识到能够把“容器”的概念无缝集成到本身的这套方案中，从而为用户提供更高层次的PaaS能力。因此，CoreOS很早就成了Docker项目的贡献者，并在短期内成为了Docker项目中第二重要的力量。

然而，这段短暂的蜜月期到2014年末就草草结束了。CoreOS公司以强烈的措辞宣布与Docker公司中止合做，并直接推出了本身研制的Rocket（后来叫rkt）容器。

此次决裂的根本缘由，正是源于Docker公司对Docker项目定位的不知足。Docker公司解决这种不知足的方法就是，让Docker项目提供更多的平台层能力，即向PaaS项目进化。而这，显然与CoreOS公司的核心产品和战略发生了严重冲突。

也就是说，Docker公司在2014年就已经定好了平台化的发展方向，而且绝对不会跟CoreOS在平台层面开展任何合做。这样看来，Docker公司在2014年12月的DockerCon上发布Swarm的举动，也就一点都不忽然了。

相较于CoreOS是依托于一系列开源项目（好比Container Linux操做系统、Fleet做业调度工具、systemd进程管理和rkt容器），一层层搭建起来的平台产品，Swarm项目则是以一个完整的总体来对外提供集群管理功能。而Swarm的最大亮点，则是它彻底使用Docker项目本来的容器管理API来完成集群管理，好比：

• 单机Docker项目：

$ docker run "个人容器复制代码

• 多机Docker项目：

$ docker run -H "个人Swarm集群API地址" "个人容器"复制代码

因此在部署了Swarm的多机环境下，用户只须要使用原先的Docker指令建立一个容器，这个请求就会被Swarm拦截下来处理，而后经过具体的调度算法找到一个合适的Docker Daemon运行起来。

这个操做方式简洁明了，对于已经了解过Docker命令行的开发者们也很容易掌握。因此，这样一个“原生”的Docker容器集群管理项目一经发布，就受到了已有Docker用户群的热捧。而相比之下，CoreOS的解决方案就显得很是另类，更不用说用户还要去接受彻底让人摸不着头脑、新造的容器项目rkt了。

固然，Swarm项目只是Docker公司从新定义“PaaS”的关键一环而已。在2014年到2015年这段时间里，Docker项目的迅速走红催生出了一个很是繁荣的“Docker生态”。在这个生态里，围绕着Docker在各个层次进行集成和创新的项目层出不穷。

而此时已经大红大紫到“不差钱”的Docker公司，开始及时地借助这波浪潮经过并购来完善本身的平台层能力。其中一个最成功的案例，莫过于对Fig项目的收购。

要知道，Fig项目基本上只是靠两我的全职开发和维护的，可它倒是当时GitHub上热度堪比Docker项目的明星。

Fig项目之因此受欢迎，在于它在开发者面前第一次提出了“容器编排”（Container Orchestration）的概念。

其实，“编排”（Orchestration）在云计算行业里不算是新词汇，它主要是指用户如何经过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、建立、删除等工做，而后由云计算平台按照这些指定的逻辑来完成的过程。

而容器时代，“编排”显然就是对Docker容器的一系列定义、配置和建立动做的管理。而Fig的工做实际上很是简单：假如如今用户须要部署的是应用容器A、数据库容器B、负载均衡容器C，那么Fig就容许用户把A、B、C三个容器定义在一个配置文件中，而且能够指定它们之间的关联关系，好比容器A须要访问数据库容器B。

接下来，你只须要执行一条很是简单的指令：

$ fig up复制代码

Fig就会把这些容器的定义和配置交给Docker API按照访问逻辑依次建立，你的一系列容器就都启动了；而容器A与B之间的关联关系，也会交给Docker的Link功能经过写入hosts文件的方式进行配置。更重要的是，你还能够在Fig的配置文件里定义各类容器的副本个数等编排参数，再加上Swarm的集群管理能力，一个活脱脱的PaaS呼之欲出。

Fig项目被收购后更名为Compose，它成了Docker公司到目前为止第二大受欢迎的项目，一直到今天也依然被不少人使用。

当时的这个容器生态里，还有不少使人眼前一亮的开源项目或公司。好比，专门负责处理容器网络的SocketPlane项目（后来被Docker公司收购），专门负责处理容器存储的Flocker项目（后来被EMC公司收购），专门给Docker集群作图形化管理界面和对外提供云服务的Tutum项目（后来被Docker公司收购）等等。

一时之间，整个后端和云计算领域的聪明才俊都聚集在了这个“小鲸鱼”的周围，为Docker生态的蓬勃发展献上了本身的智慧。

而除了这个异常繁荣的、围绕着Docker项目和公司的生态以外，还有一个势力在当时也是风头无两，这就是老牌集群管理项目Mesos和它背后的创业公司Mesosphere。

Mesos做为Berkeley主导的大数据套件之一，是大数据火热时最受欢迎的资源管理项目，也是跟Yarn项目杀得难舍难分的实力派选手。

不过，大数据所关注的计算密集型离线业务，其实并不像常规的Web服务那样适合用容器进行托管和扩容，也没有对应用打包的强烈需求，因此Hadoop、Spark等项目到如今也没在容器技术上投下更大的赌注；可是对于Mesos来讲，天生的两层调度机制让它很是容易从大数据领域抽身，转而去支持受众更加普遍的PaaS业务。

在这种思路的指导下，Mesosphere公司发布了一个名为Marathon的项目，而这个项目很快就成为了Docker Swarm的一个有力竞争对手。

虽然不能提供像Swarm那样的原生Docker API，Mesos社区却拥有一个独特的竞争力：超大规模集群的管理经验。

早在几年前，Mesos就已经经过了万台节点的验证，2014年以后又被普遍使用在eBay等大型互联网公司的生产环境中。而此次经过Marathon实现了诸如应用托管和负载均衡的PaaS功能以后，Mesos+Marathon的组合实际上进化成了一个高度成熟的PaaS项目，同时还能很好地支持大数据业务。

因此，在这波容器化浪潮中，Mesosphere公司不失时机地提出了一个名叫“DC/OS”（数据中心操做系统）的口号和产品，旨在使用户可以像管理一台机器那样管理一个万级别的物理机集群，而且使用Docker容器在这个集群里自由地部署应用。而这，对不少大型企业来讲具备着非同寻常的吸引力。

这时，若是你再去审视当时的容器技术生态，就不难发现CoreOS公司居然显得有些尴尬了。它的rkt容器彻底打不开局面，Fleet集群管理项目更是少有人问津，CoreOS彻底被Docker公司压制了。

而处境一样不容乐观的彷佛还有RedHat，做为Docker项目早期的重要贡献者，RedHat也是由于对Docker公司平台化战略不满而愤愤退出。但此时，它竟只剩下OpenShift这个跟Cloud Foundry同时代的经典PaaS一张牌能够打，跟Docker Swarm和转型后的Mesos彻底不在同一个“竞技水平”之上。

那么，事实果然如此吗？

2014年注定是一个神奇的年份。就在这一年的6月，基础设施领域的翘楚Google公司忽然发力，正式宣告了一个名叫Kubernetes项目的诞生。而这个项目，不只挽救了当时的CoreOS和RedHat，还如同当年Docker项目的横空出世同样，再一次改变了整个容器市场的格局。

第四阶段、尘埃落定

在上一次的分享中我提到，伴随着Docker公司一手打造出来的容器技术生态在云计算市场中站稳了脚跟，围绕着Docker项目进行的各个层次的集成与创新产品，也如雨后春笋般出如今这个新兴市场当中。而Docker公司，不失时机地发布了Docker Compose、Swarm和Machine“三件套”，在从新定义PaaS的方向上走出了最关键的一步。

这段时间，也正是Docker生态创业公司们的春天，大量围绕着Docker项目的网络、存储、监控、CI/CD，甚至UI项目纷纷出台，也涌现出了不少Rancher、Tutum这样在开源与商业上均取得了巨大成功的创业公司。

在2014~2015年间，整个容器社区可谓热闹非凡。

这使人兴奋的繁荣背后，却浮现出了更多的担心。这其中最主要的负面情绪，是对Docker公司商业化战略的种种顾虑。

事实上，不少从业者也都看得明白，Docker项目此时已经成为Docker公司一个商业产品。而开源，只是Docker公司吸引开发者群体的一个重要手段。不过这么多年来，开源社区的商业化其实都是相似的思路，无非是高不高调、心不心急的问题罢了。

而真正令大多数人不满意的是，Docker公司在Docker开源项目的发展上，始终保持着绝对的权威和发言权，并在多个场合用实际行动挑战到了其余玩家（好比，CoreOS、RedHat，甚至谷歌和微软）的切身利益。

那么，这个时候，你们的不满也就再也不是在GitHub上发发牢骚这么简单了。

相信不少容器领域的老玩家们都据说过，Docker项目刚刚兴起时，Google也开源了一个在内部使用多年、经历过生产环境验证的Linux容器：lmctfy（Let Me Container That For You）。

然而，面对Docker项目的强势崛起，这个对用户没那么友好的Google容器项目根本没有招架之力。因此，知难而退的Google公司，向Docker公司表示了合做的愿望：关停这个项目，和Docker公司共同推动一个中立的容器运行时（container runtime）库做为Docker项目的核心依赖。

不过，Docker公司并无认同这个明显会削弱本身地位的提议，还在不久后，本身发布了一个容器运行时库Libcontainer。此次匆忙的、由一家主导的、并带有战略性考量的重构，成了Libcontainer被社区长期诟病代码可读性差、可维护性不强的一个重要缘由。

至此，Docker公司在容器运行时层面上的强硬态度，以及Docker项目在高速迭代中表现出来的不稳定和频繁变动的问题，开始让社区叫苦连天。

这种情绪在2015年达到了一个小高潮，容器领域的其余几位玩家开始商议“切割”Docker项目的话语权。而“切割”的手段也很是经典，那就是成立一个中立的基金会。

因而，2015年6月22日，由Docker公司牵头，CoreOS、Google、RedHat等公司共同宣布，Docker公司将Libcontainer捐出，并更名为RunC项目，交由一个彻底中立的基金会管理，而后以RunC为依据，你们共同制定一套容器和镜像的标准和规范。

这套标准和规范，就是OCI（ Open Container Initiative ）。OCI的提出，意在将容器运行时和镜像的实现从Docker项目中彻底剥离出来。这样作，一方面能够改善Docker公司在容器技术上一家独大的现状，另外一方面也为其余玩家不依赖于Docker项目构建各自的平台层能力提供了可能。

不过，不难看出，OCI的成立更多的是这些容器玩家出于自身利益进行干涉的一个妥协结果。因此，尽管Docker是OCI的发起者和创始成员，它却不多在OCI的技术推动和标准制定等事务上扮演关键角色，也没有动力去积极地推动这些所谓的标准。

这，也正是迄今为止OCI组织效率持续低下的根本缘由。

眼看着OCI并没能改变Docker公司在容器领域一家独大的现状，Google和RedHat等公司因而把与第二把武器摆上了台面。

Docker之因此不担忧OCI的威胁，缘由就在于它的Docker项目是容器生态的事实标准，而它所维护的Docker社区也足够庞大。但是，一旦这场斗争被转移到容器之上的平台层，或者说PaaS层，Docker公司的竞争优点便马上捉襟见肘了。

在这个领域里，像Google和RedHat这样的成熟公司，都拥有着深厚的技术积累；而像CoreOS这样的创业公司，也拥有像Etcd这样被普遍使用的开源基础设施项目。

但是Docker公司呢？它却只有一个Swarm。

因此此次，Google、RedHat等开源基础设施领域玩家们，共同牵头发起了一个名为CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它但愿，以Kubernetes项目为基础，创建一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以Docker公司为核心的容器商业生态。

而为了打造出这样一个围绕Kubernetes项目的“护城河”，CNCF社区就须要至少确保两件事情：

1. Kubernetes项目必须可以在容器编排领域取得足够大的竞争优点；

1. CNCF社区必须以Kubernetes项目为核心，覆盖足够多的场景。

咱们先来看看CNCF社区如何解决Kubernetes项目在编排领域的竞争力的问题。

在容器编排领域，Kubernetes项目须要面对来自Docker公司和Mesos社区两个方向的压力。不难看出，Swarm和Mesos实际上分别从两个不一样的方向讲出了本身最擅长的故事：Swarm擅长的是跟Docker生态的无缝集成，而Mesos擅长的则是大规模集群的调度与管理。

这两个方向，也是大多数人作容器集群管理项目时最容易想到的两个出发点。也正由于如此，Kubernetes项目若是继续在这两个方向上作文章恐怕就不太明智了。

因此这一次，Kubernetes选择的应对方式是：Borg。

若是你看过Kubernetes项目早期的GitHub Issue和Feature的话，就会发现它们大多来自于Borg和Omega系统的内部特性，这些特性落到Kubernetes项目上，就是Pod、Sidecar等功能和设计模式。

这就解释了，为何Kubernetes发布后，不少人“抱怨”其设计思想过于“超前”的缘由：Kubernetes项目的基础特性，并非几个工程师忽然“拍脑壳”想出来的东西，而是Google公司在容器化基础设施领域多年来实践经验的沉淀与升华。这，正是Kubernetes项目可以从一开始就避免同Swarm和Mesos社区同质化的重要手段。

因而，CNCF接下来的任务就是，如何把这些先进的思想经过技术手段在开源社区落地，并培育出一个认同这些理念的生态？这时，RedHat就发挥了重要做用。

当时，Kubernetes团队规模很小，可以投入的工程能力也十分紧张，而这偏偏是RedHat的长处。更可贵的是，RedHat是世界上为数很少的、能真正理解开源社区运做和项目研发真谛的合做伙伴。

因此，RedHat与Google联盟的成立，不只保证了RedHat在Kubernetes项目上的影响力，也正式开启了容器编排领域“三国鼎立”的局面。

这时，咱们再从新审视容器生态的格局，就不难发现Kubernetes项目、Docker公司和Mesos社区这三大玩家的关系已经发生了微妙的变化。

其中，Mesos社区与容器技术的关系，更像是“借势”，而不是这个领域真正的参与者和领导者。这个事实，加上它所属的Apache社区固有的封闭性，致使了Mesos社区虽然技术最为成熟，却在容器编排领域鲜有创新。

这也是为什么，Google公司很快就把注意力转向了动做更加激进的Docker公司。

有意思的是，Docker公司对Mesos社区也是相似的见解。因此从一开始，Docker公司就把应对Kubernetes项目的竞争摆在了首要位置：一方面，不断强调“Docker Native”的“重要性”，另外一方面，与Kubernetes项目在多个场合进行了直接的碰撞。

不过，此次竞争的发展态势，很快就超过了Docker公司的预期。

Kubernetes项目并无跟Swarm项目展开同质化的竞争，因此“Docker Native”的说辞并无太大的杀伤力。相反地，Kubernetes项目让人耳目一新的设计理念和号召力，很快就构建出了一个不同凡响的容器编排与管理的生态。

就这样，Kubernetes项目在GitHub上的各项指标开始一骑绝尘，将Swarm项目远远地甩在了身后。

有了这个基础，CNCF社区就能够放心地解决第二个问题了。

在已经囊括了容器监控事实标准的Prometheus项目以后，CNCF社区迅速在成员项目中添加了Fluentd、OpenTracing、CNI等一系列容器生态的知名工具和项目。

而在看到了CNCF社区对用户表现出来的巨大吸引力以后，大量的公司和创业团队也开始专门针对CNCF社区而非Docker公司制定推广策略。

面对这样的竞争态势，Docker公司决定更进一步。在2016年，Docker公司宣布了一个震惊全部人的计划：放弃现有的Swarm项目，将容器编排和集群管理功能所有内置到Docker项目当中。

显然，Docker公司意识到了Swarm项目目前惟一的竞争优点，就是跟Docker项目的无缝集成。那么，如何让这种优点最大化呢？那就是把Swarm内置到Docker项目当中。

实际上，从工程角度来看，这种作法的风险很大。内置容器编排、集群管理和负载均衡能力，当然可使得Docker项目的边界直接扩大到一个完整的PaaS项目的范畴，但这种变动带来的技术复杂度和维护难度，长远来看对Docker项目是不利的。

不过，在当时的大环境下，Docker公司的选择恐怕也带有一丝背注一掷的意味。

而Kubernetes的应对策略则是反其道而行之，开始在整个社区推动“民主化”架构，即：从API到容器运行时的每一层，Kubernetes项目都为开发者暴露出了能够扩展的插件机制，鼓励用户经过代码的方式介入到Kubernetes项目的每个阶段。

Kubernetes项目的这个变革的效果立竿见影，很快在整个容器社区中催生出了大量的、基于Kubernetes API和扩展接口的二次创新工做，好比：

• 目前热度极高的微服务治理项目Istio；

• 被普遍采用的有状态应用部署框架Operator；

• 还有像Rook这样的开源创业项目，它经过Kubernetes的可扩展接口，把Ceph这样的重量级产品封装成了简单易用的容器存储插件。

就这样，在这种鼓励二次创新的总体氛围当中，Kubernetes社区在2016年以后获得了空前的发展。更重要的是，不一样于以前局限于“打包、发布”这样的PaaS化路线，这一次容器社区的繁荣，是一次彻底以Kubernetes项目为核心的“百花争鸣”。

面对Kubernetes社区的崛起和壮大，Docker公司也不得不面对本身豪赌失败的现实。但在早前拒绝了微软的天价收购以后，Docker公司实际上已经没有什么回旋余地，只能选择逐步放弃开源社区而专一于本身的商业化转型。

因此，从2017年开始，Docker公司先是将Docker项目的容器运行时部分Containerd捐赠给CNCF社区，标志着Docker项目已经全面升级成为一个PaaS平台；紧接着，Docker公司宣布将Docker项目更名为Moby，而后交给社区自行维护，而Docker公司的商业产品将占有Docker这个注册商标。

Docke公司这些举措背后的含义很是明确：它将全面放弃在开源社区同Kubernetes生态的竞争，转而专一于本身的商业业务，而且经过将Docker项目更名为Moby的举动，将本来属于Docker社区的用户转化成了本身的客户。

2017年10月，Docker公司出人意料地宣布，将在本身的主打产品Docker企业版中内置Kubernetes项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。

2018年1月30日，RedHat宣布斥资2.5亿美圆收购CoreOS。

2018年3月28日，这一切纷争的始做俑者，Docker公司的CTO Solomon Hykes宣布辞职，曾经纷纷扰扰的容器技术圈子，到此尘埃落定。

如今，我来总结一下今天的主要内容

容器技术圈子在短短几年里发生了不少变数，但不少事情其实也都在情理之中。就像Docker这样一家创业公司，在经过开源社区的运做取得了巨大的成功以后，就不得不面对来自整个云计算产业的竞争和围剿。而这个产业的垄断特性，对于Docker这样的技术型创业公司其实天生就不友好。

在这种局势下，接受微软的天价收购，在大多数人看来都是一个很是明智和实际的选择。但是Solomon Hykes却多少带有一些理想主义的影子，既然不甘于“寄人篱下”，那他就必须带领Docker公司去对抗来自整个云计算产业的压力。

只不过，Docker公司最后选择的对抗方式，是将开源项目与商业产品紧密绑定，打造了一个极端封闭的技术生态。而这，其实违背了Docker项目与开发者保持亲密关系的初衷。相比之下，Kubernetes社区，正是以一种更加温和的方式，承接了Docker项目的未尽事业，即：以开发者为核心，构建一个相对民主和开放的容器生态。

这也是为什么，Kubernetes项目的成功实际上是必然的。

如今，咱们很难想象若是Docker公司最初选择了跟Kubernetes社区合做，现在的容器生态又将会是怎样的一番景象。不过咱们能够确定的是，Docker公司在过去五年里的风云变幻，以及Solomon Hykes本人的传奇经历，都已经在云计算的长河中留下了浓墨重彩的一笔。

戳此查看：第一阶段崭露头角

戳此查看全文：极客时间《深刻剖析Kubernetes》