|
|
# 01 | 预习篇 · 小鲸鱼大事记（一）：初出茅庐
|
|
|
|
|
|
你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之初出茅庐。
|
|
|
|
|
|
**如果我问你，现今最热门的服务器端技术是什么？想必你不假思索就能回答上来：当然是容器！可是，如果现在不是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公司离自己的理想真的只有一步之遥。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
2013~2014年，以Cloud Foundry为代表的PaaS项目，逐渐完成了教育用户和开拓市场的艰巨任务，也正是在这个将概念逐渐落地的过程中，应用“打包”困难这个问题，成了整个后端技术圈子的一块心病。
|
|
|
|
|
|
Docker项目的出现，则为这个根本性的问题提供了一个近乎完美的解决方案。这正是Docker项目刚刚开源不久，就能够带领一家原本默默无闻的PaaS创业公司脱颖而出，然后迅速占领了所有云计算领域头条的技术原因。
|
|
|
|
|
|
而在成为了基础设施领域近十年难得一见的技术明星之后，dotCloud公司则在2013年底大胆改名为Docker公司。不过，这个在当时就颇具争议的改名举动，也成为了日后容器技术圈风云变幻的一个关键伏笔。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
你是否曾经研发过类似PaaS的项目？你碰到过应用打包的问题吗，又是如何解决的呢？
|
|
|
|
|
|
感谢收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。
|
|
|
|