docker的发展历程
2013年的后端技术领域已经太久没有出现让人振奋的东西了。曾经被人们天天挂念在口中的云计算技术也仅仅是局限于虚拟机中，这一切好像没有什么改变，人们的生产方式与生成习惯也一直停留，云计算的提出并没有给实际的生产环境带来重大的改变。而恰巧益Cloud Foundry为代变的开源Pass项目作为云计算唯一的实用性技术被应用和保留。我们心心想念的PaaS理念好像只能依据Cloud Foundry进入到人们的视野之中。可是这个时候就突然冒出来了一只活波的蔚蓝色鲸鱼，它更像是一艘大轮船经历过大西洋、太平洋、乘风破浪，将一个一个已经包装好的、独立的、完整的货物运到了彼岸。每一个人，都可以根据自己的需要在其中找到适合自己的货物(沙盒)。
其实“容器”本身并不是什么新鲜的东西，在Clound Foundry中也是有容器的一部分，只不过人们把它当成了底层的一种封装。Pass项目的核心观念是“应用托管”即我们只要编写好软件，写好运行脚本，我们只要丢给云平台就可以了。其他的一些管理，监控，应用编排等涉及到生产环境中的管理、运维方面我们不用太关心。但是在我们的部署过程中难免会遇到的问题就是我们的本地运行环境和生产环境不一致。针对这个问题Cloud Foundry的解决方法与docker是一致的，就是同样运用Cgroups(限制权限)与Namespace(规定资源视图),打包一个一个沙盒,使得虚拟机能够在运行时就具有固定的环境。那docker的创新点在哪？docker为什么能够火起来？
- docker将打包部署简单化，打包成一个个镜像，保持本地环境和生产中的云环境的高度一致性
- 为开发者提供友好的设计和封装
Docker给PaaS世界的“降维打击”，其实是提供了一种便利的打包机制，这种打包机制直接打包了整个应用运行所需要的整个操作系统，从而保证云端和本地环境的一致性，避免用户过多的在生产环境中重视环境的问题。
2014年的docker公司发布了容器集群管理项目Swarm，一时间使得容器化技术一下子热闹了起来。
在docker大红大紫的时候，Fig项目也应运而生，Fig是用于docker容器的编排，将docker命令实现的定义、配置、创建以及容器的启动结构化，用类似编码的形式逻辑化，将容器之间的关系更清晰的表达。后来Fig项目就被Docker公司收购并改名成我们认识的Compose。
当docker强势占据着容器领域的巨大份额的时候呀，也是同样的2014年6月，基于谷歌内部强大的Borg系统而开发出来的kubernetes横空处世，刷新了人们对容器的理解。
2015年，OCI标准提出，容器进行时和镜像的实现从Docker项目中分割出来，使得其他的容器技术不需要依赖于Docker项目就可以构建自己的容器平台。
在2016年，人们认识到容器技术本身的价值时在于容器的编排，而此时的Docker项目缺令人惊讶的放弃了Swarm项目，而是想将容器的编排和集群的管理功能添加到Docker项目当中。而Kubernetes却与Docker不同的是推进民主化架构，使得通过暴露Kubernetes API的方法，让更多的人来不断丰富kubernetes的插件。
2017年，Docker公司由于自己的决策性失误而不得不放弃开源社区，而转型商业化。而Docker也将容器运行时捐赠给了CNCF社区，并改名Moby。
