深入刨析容器（一）:容器的前世今生

题外话，从左耳听风那里听到的话，技术的世界再变，你要找到不变的去学习，也就是说其实变来变去的只不过是外层理念封装的概念，实质的话本质还是基础，把基础打好才是无敌，这也点醒了我，要好好的学习基础知识，才能以不变应万变。

然后在极客时间溜达的时候，又看到一句话，学一门技术你要知道为什么会用它而不是用其他的，它的出现是为了解决什么痛点，而不是炫技，所以才有了此刻的文章，为什么会有容器，为什么Docker和K8S取得了最终容器的胜利，这场战争就此拉开。

本章来源学习极客时间的 《深入剖析 Kubernetes》张磊 而整理的笔记。

1.1.初出茅庐

10年前的今天，那时已有云计算的Paas平台，以Cloud Foundry为代表的，可以将应用打包，写一些脚本配置，那么执行一行指令即可安装启动，但是由于本地系统与云系统不一致，很多软件应用不适配，需要程序员各种试错，才能写一个满意的脚本执行不出问题，但是如果换成另一个系统，或者是别的应用，则还需要试错配置才能达到满意的配置，这就导致了Cloud Foundry衰败。

半路杀出来个Docker，它其他的都是和Cloud Foundry源码大差不差，唯独一个创新，让它在后面的地位奠下了基础，这个创新就是Docker 镜像，Docker能够将操作系统的等应用文件（操作系统内核没有打包）包打成个镜像，这个压缩包包含了完整的操作系统文件和目录，也就是包含了这个应用运行所需要的所有依赖，这样你在本地测试能使用并打包，到Docker上不会出现问题，不用经过复杂的的配置试错阶段，所以一经问世则被很多的开发者追捧。

容器最核心的就是运行应用的隔离环境，或者说“沙盒”，就是所谓的“容器”，而Docker也是，在docker run就会创建“沙盒”，然后调用操作系统Cgroups 和 Namespace 机制创建出来的隔离环境，Cgroups和Namespace后面会讲，这也是Docker重要的实现容器的方法。

1.2.崭露头角

后面Docker的公司出于种种原因将公司名称改为Docker，专注于开发者用户，而不是老板，对于开发者用户便利，自然而然就有受众群体，让它风光无两。

1.3.群雄并起

Docker在最热的时候立马发现了自己的短处，只是提供应用的打包肯定是站不住脚的，所以想要发展还是要自己做Pass平台，刚开始有其他的平台与Docker合作，如CoreOS 公司，但最终Docker的发展影响到了CoreOS的发展而决裂告终，随后Docker就发布了Swarm，容器集群管理，命令基本和单机的Docker差不多，所以很受Docker使用者的追捧。

Docker前期发展让Docker很有资本，所以收购了很多好项目去完善自己的平台能力，如Fig项目，Fig项目第一次提出了容器编排，其实，“编排”（Orchestration）在云计算行业里不算是新词汇，它主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。

Fig的工作不难，假如现在有应用容器A和数据库容器B，那么Fig允许用户把A,B两个容器定义在一个配置文件中，并且可以指定他们的关系，比如容器A需要访问数据库B，然后执行一条指令即可 fig up，然后fig把容器的定义和配置交给Docker api依次创建，并启动。Fig 项目被收购后改名为 Compose，到目前为止这个Compose也有很多人使用。

还有很多令人眼前一亮的开源项目或公司。比如，专门负责处理容器网络的 SocketPlane 项目（后来被 Docker 公司收购），专门负责处理容器存储的 Flocker 项目（后来被 EMC 公司收购），专门给 Docker 集群做图形化管理界面和对外提供云服务的 Tutum 项目（后来被 Docker 公司收购）等等

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

1.4 尘埃落定

由于Docker垄断性发展，导致了其他厂商的不满，他们联合Docker做起了中间基金，大家一起制定了OCI（ Open Container Initiative ），容器的标准和规范，OCI 的提出，意在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来。虽然由Docker牵头，但是Docker并没有把时间过多的浪费在这，OCI也并没有剥夺Docker的地位，因为并没有涉及到Docker最根本的利益-容器平台化也就是Paas，所以其他厂商-谷歌以及红帽等一起联合发起了CNCF（Cloud Native Computing Foundation），这个基金会的目的也只是为了推K8s项目，用来抵抗Docker，k8s之所以优秀，是其谷歌红帽等其他公司本身优秀的技术积累，K8s则是来自于 Borg 和 Omega 系统的内部特性，这些特性落到 Kubernetes 项目上，就是 Pod、Sidecar 等功能和设计模式。而且K8S吸取百家所长，积极发展社区，将各个方面都放开，能够轻易的被其他厂家插拔，慢慢的，Docker就打不过k8s，并出现了尬尴的局面，最终随着创作者从Docker公司离职而尘埃落定。

这一节讲了容器出现的始末，下一节会讲容器的内部概念，让我们一点点深入容器，揭开它神秘的面纱。