小鲸鱼大事记 | Docker诞生历程之初出茅庐

做者：张磊

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

 
你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之初出茅庐。

第一阶段、初出茅庐

2013~2014年，以Cloud Foundry为表明的PaaS项目，逐渐完成了教育用户和开拓市场的艰巨任务，也正是在这个将概念逐渐落地的过程当中，应用“打包”困难这个问题，成了整个后端技术圈子的一块心病。

Docker项目的出现，则为这个根本性的问题提供了一个近乎完美的解决方案。这正是Docker项目刚刚开源不久，就可以带领一家本来默默无闻的PaaS创业公司脱颖而出，而后迅速占领了全部云计算领域头条的技术缘由。

而在成为了基础设施领域近十年可贵一见的技术明星以后，dotCloud公司则在2013年末大胆更名为Docker公司。不过，这个在当时就颇具争议的更名举动，也成为了往后容器技术圈风云变幻的一个关键伏笔。

若是我问你，现今最热门的服务器端技术是什么？想必你不假思索就能回答上来：固然是容器！但是，若是如今不是2018年而是2013年，你的回答还能这么斩钉截铁么？

2013年，被人们寄予厚望的云计算技术，从当初虚无缥缈的概念蜕变成了实实在在的虚拟机和帐单。而相比于的如日中天AWS和盛极一时的OpenStack，以Cloud Foundry为表明的开源PaaS项目，却成为了当时云计算技术中的一股清流。

这时，Cloud Foundry项目已经基本度过了最艰难的概念普及和用户教育阶段，吸引了包括百度、京东、华为、IBM等一大批国内外技术厂商，开启了以开源PaaS为核心构建平台层服务能力的变革。若是你有机会问问当时的云计算从业者们，他们十有八九都会告诉你：PaaS的时代就要来了！

这个说法其实一点儿没错，若是不是后来一个叫Docker的开源项目忽然冒出来的话。

事实上，当时还名叫dotCloud的Docker公司，也是这股PaaS热潮中的一份子。只不过相比于Heroku、Pivotal、Red Hat等PaaS弄潮儿们，dotCloud公司实在是太微不足道了，而它的主打产品因为跟主流的Cloud Foundry社区脱节，长期以来也无人问津。眼看就要被如火如荼的PaaS风潮抛弃，dotCloud公司却作出了这样一个决定：开源本身的容器项目Docker。

显然，这个决定在当时根本没人在意。

“容器”这个概念历来就不是什么新鲜的东西，也不是Docker公司发明的。即便在当时最热门的PaaS项目Cloud Foundry中，容器也只是其最底层、最没人关注的那一部分。说到这里，我正好以当时的事实标准Cloud Foundry为例，来解说一下PaaS技术。

PaaS项目被你们接纳的一个主要缘由，就是它提供了一种名叫“应用托管”的能力。在当时，虚拟机和云计算已是比较广泛的技术和服务了，那时主流用户的广泛用法，就是租一批AWS或者OpenStack的虚拟机，而后像之前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。

固然，这个部署过程不免会碰到云端虚拟机和本地环境不一致的问题，因此当时的云计算服务，比的就是谁能更好地模拟本地服务器环境，能带来更好的“上云”体验。而PaaS开源项目的出现，就是当时解决这个问题的一个最佳方案。

举个例子，虚拟机建立好以后，运维人员只须要在这些机器上部署一个Cloud Foundry项目，而后开发者只要执行一条命令就能把本地的应用部署到云上，这条命令就是：

$ cf push "个人应用"复制代码

是否是很神奇？

事实上，像Cloud Foundry这样的PaaS项目，最核心的组件就是一套应用的打包和分发机制。Cloud Foundry为每种主流编程语言都定义了一种打包格式，而“cf push”的做用，基本上等同于用户把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上Cloud Foundry的存储中。接着，Cloud Foundry会经过调度器选择一个能够运行这个应用的虚拟机，而后通知这个机器上的Agent把应用压缩包下载下来启动。

这时候关键来了，因为须要在一个虚拟机上启动不少个来自不一样用户的应用，Cloud Foundry会调用操做系统的Cgroups和Namespace机制为每个应用单首创建一个称做“沙盒”的隔离环境，而后在“沙盒”中启动这些应用进程。这样，就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。

这，正是PaaS项目最核心的能力。而这些Cloud Foundry用来运行应用的隔离环境，或者说“沙盒”，就是所谓的“容器”。

而Docker项目，实际上跟Cloud Foundry的容器并无太大不一样，因此在它发布后不久，Cloud Foundry的首席产品经理James Bayer就在社区里作了一次详细对比，告诉用户Docker实际上只是一个一样使用Cgroups和Namespace实现的“沙盒”而已，没有什么特别的黑科技，也不须要特别关注。

然而，短短几个月，Docker项目就迅速崛起了。它的崛起速度如此之快，以致于Cloud Foundry以及全部的PaaS社区还没来得及成为它的竞争对手，就直接被宣告出局了。那时候，一位多年的PaaS从业者曾经如此感慨道：这简直就是一场“降维打击”啊。

难道这一次，连闯荡多年的“老江湖”James Bayer也看走眼了么？

并无。

事实上，Docker项目确实与Cloud Foundry的容器在大部分功能和实现原理上都是同样的，可恰恰就是这剩下的一小部分不同的功能，成了Docker项目接下来“呼风唤雨”的不二法宝。

这个功能，就是Docker镜像。

恐怕连Docker项目的做者Solomon Hykes本身当时都没想到，这个小小的创新，在短短几年内就如此迅速地改变了整个云计算领域的发展历程。

我前面已经介绍过，PaaS之因此可以帮助用户大规模部署应用到集群里，是由于它提供了一套应用打包的功能。可恰恰就是这个打包功能，却成了PaaS往后不断遭到用户诟病的一个“软肋”。

出现这个问题的根本缘由是，一旦用上了PaaS，用户就必须为每种语言、每种框架，甚至每一个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却须要作不少修改和配置工做才能在PaaS里运行起来。而这些修改和配置，并无什么经验能够借鉴，基本上得靠不断试错，直到你摸清楚了本地应用和远端PaaS匹配的“脾气”才可以搞定。

最后结局就是，“cf push”确实是能一键部署了，可是为了实现这个一键部署，用户为每一个应用打包的工做可谓一波三折，费尽心机。

而Docker镜像解决的，偏偏就是打包这个根本性的问题。所谓Docker镜像，其实就是一个压缩包。可是这个压缩包里的内容，比PaaS的应用可执行文件+启停脚本的组合就要丰富多了。实际上，大多数Docker镜像是直接由一个完整操做系统的全部文件和目录构成的，因此这个压缩包里的内容跟你本地开发和测试环境用的操做系统是彻底同样的。

这就有意思了：假设你的应用在本地运行时，能看见的环境是CentOS 7.2操做系统的全部文件和目录，那么只要用CentOS 7.2的ISO作一个压缩包，再把你的应用可执行文件也压缩进去，那么不管在哪里解压这个压缩包，均可以获得与你本地测试时同样的环境。固然，你的应用也在里面！

这就是Docker镜像最厉害的地方：只要有这个压缩包在手，你就可使用某种技术建立一个“沙盒”，在“沙盒”中解压这个压缩包，而后就能够运行你的程序了。

更重要的是，这个压缩包包含了完整的操做系统文件和目录，也就是包含了这个应用运行所须要的全部依赖，因此你能够先用这个压缩包在本地进行开发和测试，完成以后，再把这个压缩包上传到云端运行。

在这个过程当中，你彻底不须要进行任何配置或者修改，由于这个压缩包赋予了你一种极其宝贵的能力：本地环境和云端环境的高度一致！

这，正是Docker镜像的精髓。

那么，有了Docker镜像这个利器，PaaS里最核心的打包系统一会儿就没了用武之地，最让用户抓狂的打包过程也随之消失了。相比之下，在当今的互联网里，Docker镜像须要的操做系统文件和目录，可谓唾手可得。

因此，你只须要提供一个下载好的操做系统文件与目录，而后使用它制做一个压缩包便可，这个命令就是：

$ docker build "个人镜像"复制代码

一旦镜像制做完成，用户就可让Docker建立一个“沙盒”来解压这个镜像，而后在“沙盒”中运行本身的应用，这个命令就是：

$ docker run "个人镜像"复制代码

固然，docker run建立的“沙盒”，也是使用Cgroups和Namespace机制建立出来的隔离环境。我会在后面的文章中，详细介绍这个机制的实现原理。

因此，Docker项目给PaaS世界带来的“降维打击”，实际上是提供了一种很是便利的打包机制。这种机制直接打包了应用运行所须要的整个操做系统，从而保证了本地环境和云端环境的高度一致，避免了用户经过“试错”来匹配两种不一样运行环境之间差别的痛苦过程。

而对于开发者们来讲，在终于体验到了生产力解放所带来的痛快以后，他们天然选择了用脚投票，直接宣告了PaaS时代的结束。

不过，Docker项目当然解决了应用打包的难题，但正如前面所介绍的那样，它并不能代替PaaS完成大规模部署应用的职责。

遗憾的是，考虑到Docker公司是一个与本身有潜在竞争关系的商业实体，再加上对Docker项目普及程度的错误判断，Cloud Foundry项目并无第一时间使用Docker做为本身的核心依赖，去替换本身那套饱受诟病的打包流程。

反却是一些机敏的创业公司，纷纷在第一时间推出了Docker容器集群管理的开源项目（好比Deis和Flynn），它们通常称本身为CaaS，即Container-as-a-Service，用来跟“过期”的PaaS们划清界限（这里做者重复了最后几个字，须要剪掉）。

而在2014年末的DockerCon上，Docker公司雄心勃勃地对外发布了自家研发的“Docker原生”容器集群管理项目Swarm，不只将这波“CaaS”热推向了一个史无前例的高潮，更是寄托了整个Docker公司从新定义PaaS的宏伟愿望。

在2014年的这段巅峰岁月里，Docker公司离本身的理想真的只有一步之遥。