专题合集

《云原生系列专题分享合集》

目录

• 前言
• 群龙无首的那一年
• 神来一笔的那一年
• 风云卷起的那一年

前言

当我们提起 Docker 的时候，我们说的是 Docker 公司？Docker 容器？Docker 镜像？还是 Docker 集群？

很多时候我们都喜欢看到一个项目，就拉下来读代码，埋头去专研。

但问题来了，这个项目设计的初衷是什么，为什么它要这么设计，它经历了哪些发展？

相比于我告诉你 Docker 是什么，不如带你来看下 Docker 的披荆斩棘史，这可能比我告诉你 Docker 的常用指令更有意义。

群龙无首的那一年

容器这个概念，其实不是 Docker 公司提出来，比如 13 年 Cloud Foundry 这个开源的 PaaS 项目大热时，就已经有应用了，只是容器是里面无人问津的技术罢了。

当时虚拟机和云计算技术已经开始普遍，大家都喜欢租一批 AWS 或者 OpenStack 的虚拟机，然后把自己的服务部署上去，其实也就是所谓的 "上云"。

所以国外在很早，就有 "上云" 的这样一种意识，不像我们现在还在大力推广 "上云"，甚至国内云行业还处于亏损的起步期，占着极低的市场比。

这里有很多因素，感兴趣可以后面探讨，这里就不继续展开了。

Cloud Foundry 当时主要是提供了一种 "应用托管" 的能力，可以理解为帮助你优化 "上云" 的体验。

比如如果我想把我的应用部署到云上，我只需要执行一条指令：

cf push "my app"

就搞定了。

这也是为什么当时类似这样的 PaaS 大火的原因，核心其实就是两个能力： build & push。

build 顾名思义，就是能把你的应用按照一定的格式去打包，生成可执行的应用和启动脚本。

push 顾名思义，就是能把你打包好的应用，部署到虚拟机里面，利用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个 "沙盒 SandBox" 的隔离环境。

所以说到这里，你就会发现，其实容器技术的核心，也不过是利用操作系统的 Cgroups 和 Namespace 机制实现的隔离 SandBox 罢了。

而 Cgroups 这样的虚拟化技术，早在零几年的时候 Google 内部就已经大规模使用，并开源出来，进入了 Linux 内核主线。

所以说 Docker 公司如果只靠容器这个技术，怎么跟这些巨头打架？

更何况，那个时候 Docker 公司还不叫 Docker，而是一家名为 dotCloud 的创业小公司，它也只是这股 PaaS 热潮当中诞生出来的渺小一份子罢了。

眼看着大家都要如火如荼参与到 PaaS 的变革，而自己却无人问津，dotCloud 公司突然决定，开源自己的项目，并命名为 Docker。

至此，Docker 在云原生历史上留下了浓墨的一笔。

神来一笔的那一年

前面讲到，Cloud Foundry 依靠自己的打包部署能力，成为了追捧的巨星。

但是它其实也有自己的痛点，那就是云上环境和本地环境是不一致的，而且打包流程和方式并没有一套标准模板。

甚至这个打包的困难，成为了当时整个云技术圈子的一大心病。

这也就导致了，服务上云之后，会出现各种奇奇怪怪的问题，甚至需要反复调试和优化你的打包流程和方式，来迎合你虚拟机的脾气，这想想就让人苦不堪言。

所以 Docker 项目开源之后，Docker image 横空出世，打遍天下无敌手。哪怕是 Docker 项目的作者 Solomon Hykes，可能都没有想到，就是这样一个小小的创新，一统容器江山。

跟 Cloud Foundry 不一样的是，Docker image 提供了一种云上环境可以与本地环境同步的能力。

比如我本地开发环境是 CentOS7，那我只需要把 CentOS7 系统的 iso 镜像放到容器里面运行，再把我的应用放进去，那不就代表就算云上运行的应用，也跟我本地的开发环境保持一致了吗？

而且打包和部署，Docker 也做到了极简。

比如打包：

docker build "my image"

比如部署：

docker run "my image"

而且对于 image 镜像的制作，Docker 项目还提供了一套 Dockerfile 的模板流程，把镜像制作的过程，优化成是一套具有标准指令集的流程。

比如制作 image:

FROM CentOS7
ADD my code
RUN build my code
ENTRYPOINT run my code 

这简直是对 PaaS 世界的一场降维打击。

相比于 Cloud Foundry 暴脾气捉摸不定的女汉子，Docker 成为了大众心仪的女神。

一时间，Docker 成为了最热门的开源项目，各种人才开始纷纷涌入投入到这个建设的浪潮中，完善 Docker 的生态圈。

风云卷起的那一年

Docker 就是个刚创业的小公司，凭什么，啥玩意？

CoreOS 公司不服了，推出 rkt 容器，依旧无招架之力。

Google 公司不服了，推出 lmctfy(Let Me Contain That For You) 容器，依旧无法力挽狂澜。

而 Docker 再次打出一张王牌 Fig，第一次提出了 "容器编排" (Container Orchestration) 的概念。

我讲 Fig 你可能会有点陌生，我说 docker-compose，你可能就恍然大悟了，Fig 就是 Compose 的前身。

编排虽然不是新概念，但是容器编排却是新的。

比如我有三个服务，一个前端，一个后端，一个数据库，我可以定义他们之间的关系。

比如前端可以访问后端，后端可以访问数据库，前端不能访问数据库。

比如前端要等后端启动完成才启动，而后端要等数据库启动完成才启动。

比如前端我要暴露 80 端口，后端我要暴露 8000 端口，数据库我要暴露 3306 端口。

这些规则的定义，都可以在 Fig 里面被编排出来。

而最后，你只需要：

fig up

所有的容器，就会按照你想要编排的方式，进行部署和运行。

就这样，告别了 Cloud Foundry 时代，Docker 用全新的方式定义了 PaaS，一如它宣传的口号，"Build, Ship and Run Any App, Anywhere"。

面对 Microsoft (微软) 公司 40 亿美金的收购，这家员工总数仅为 250 人的容器技术初创企业，say no。

Docker 的野心不止于此。

14 年是 Docker 离他们梦想最近的一年，如果不是后来 kubernetes 的横空出现。

......

未完待续，有空就开更。