容器随笔

让我们把时间放到2013年，当时最火的技术是什么呢，是以cloud foundry为代表的开源pass项目，cloudy foundy项目已经度过了最艰难的用户概念普及和用户教育阶段，吸引了包括百度，京东，华为，等一大批技术厂商，开始了以来源pass项目为核心构建平台服务能力的变革，基本上pass可是说是入日中天，但是这个时候一个叫docker的开源项目突然冒了出来，docker公司当时还叫dotcloud，当时发发展前景并不好，他突然做出了一个决定，开源自己的容器项目docker。

刚开始的时候，其实这个举动也没有引起多大的风浪，因容器这个概念从来就不是什么新鲜的东西，即便是在当时最火的开源pass项目cloud foundy中，容器也是最底层的东西，最没人关注的那一部分。

 

这个说一下pass，其实什么是pass呢，pass项目被大家主动接受的一个主要原因就是，它提供了一种应用托管能力，

在当时虚拟机和云计算已经是普遍的技术和服务了，当时大家的普遍做法，就是租一批aws或者opensatck的虚拟机，然后想管理物理机哪些，用脚本或者手工的方式在上面跑着，这个过程肯定会遇到云端虚拟机和本地环境不一致的问题，当时的云计算服务器，比的就是谁能更好的模拟本地服务器环境，谁能带来更好的上云的体验，而pass平台的出现，就是当时解决这个问题的最佳方案，

 

先发cloud foundry这样的pass项目，最核心的组件就是一套应用的打包和分发机制，cloud foundry为每一种主流语言都定义了一种打包格式，把用户的应用的可执行文件和启动脚本，放在一个压缩包里面，上传到pass 平台的存储中，然后通过调度器选择一个可以运行的虚拟机，这个时候关键来了，由于在一个虚拟机上启动来自多个不同用户的应用，pass平台会调用操作系统的cgroups和namespace机制，为每一个用户创建一个沙盒一样的隔离环境，然后把这些应用启动起来，就是容器，这样就实现了多个用户的应用互不干涉的跑在虚拟机里。

这就是pass平台的核心能力，而这个pass实现隔离的环境就是容器。

 

docker项目，实际上跟cloud foundry（pass 平台）的容器并没有太大的不同。

但是docker在短短几个月快速崛起，可以说对所有的pass社区是一个降维打击，docker项目和pass的容器大部分功能和实现原理都是相同的，剩下的这一小部分的不同，成为了docker 项目接下来呼风唤雨的法宝。

 

这个功能就是docker的镜像。

 

前面说过pass项目之所以能够帮助用户快速大规模的应用，是因为他提供了一个应用打包功能，可偏偏就是这个打包功能，成为了他的一个软肋。

出现这个问题的原因是，一旦用了pass平台，用户就必须为每种语言每中应用，甚至每个版本打一个包，这个打包过程没有任何章法可寻，更麻烦的是明明在本地运行的很好的应用，缺需要做很多的配置才能在pass上跑起来，而这些配置却没有一点经验可以借鉴，基本上得靠不断试错，直到你搞清了本地应用和pass平台的脾气。

 

最后的结局就是确实能一键部署，但是为了这个部署，一波三折。

 

而docker镜像解决的，恰恰就是打包这个根本性的过程，所谓的docker镜像，本质上就是压缩包，但是这个压缩包却比pass平台压缩包的内容应用加启动脚本丰富多了，docker镜像本质上就是一个完整的操作系统的所有文件和目录，结构组成，这个压缩包的内容和你本地测试是一样的环境，你的应用也在里面。

 

这就是docker厉害的地方，这要这个压缩包在手，你在沙盒里解压你的压缩包，然后就可以运行你的程序了。

这个过程你不需要做任何修改，这个压缩包赋予我们的能力是本地和云端环境高度一致。

 

docker项目给pass项目的降维打击就是提供了一种非常便利的打包机制，这种机制直接打包了应用所需要的整个操作系统，从而保证云端环境和本地环境高度一致，避免用户通过试错来匹配两种不通运行环之间差异的痛苦过程。

 

对于，开发者来说，在体会到docker项目带来的优点，象征着pass时代的结束。

 

 

不过遗憾的是考虑到docker公司的竞争关系，cloudy doundy并没有第一时间把docker作为自己的核心依赖。

反而很多创业公司纷纷在第一时间推出自己的docker容器集群管理项目，程自己为caas，用来和pass挂清界限

 

docker项目一方面之所以能取的这么高的关注，一方面是解决应用打包和发布这个运维难题，另一个方便是他把一个纯后端的的技术概念，通过友好的封装和设计，交到了开发者手里。

你不需要精通什么tcp，也没有必要懂什么liunx内核原理，哪怕是一个前端工程师，都可以把自己的代码打成一个到处运行的包，受众群体的变革也是docker成功原因之一。

一时之间，容器化代替平台化，成为了基础设施领域的热门词汇。

 

不过docker项目虽然解决了应该打包的难题，但是他并不能代替pass完成大规模的应用。

 

2014年底docker公司对外发布了自家研发的容器集群项目docker swarm，而swarm项目才是才是承载docker的希望所在，因为docker公司明白，虽然docker项目备受大家喜爱，但是用户最后要部署还是他们的网站，服务，数据库，这就意味着只有能真正为用户提供平台层能力的工具，才能成为用户真正愿意付费的产品。

 

swarm项目一经发布，备受大家喜爱，这时候docker公司已经到了大红大紫的地步，dockwe为了进一步实现自己的平台化，开始收购，最著名的docker compose服务编排这个工具就是在这个时候收购的。

 

除了这个异常繁荣的，围绕着docker公司和项目之外，还有一个势头在当时也是风头无限，就是老牌集群管理项目meros和mesosphere。

mersos有一个独特额竞争力，就是超大规模集群管理经验，mesos在早几年前就通过了上万台节点的验证，后来有发布了一个marathon的项目，实现了应该托管和负载均衡的能力，很快成为了docker swarm的竞争对手。

 

docker公司越来越大，引起了其余几个容器老大不满，谷歌曾想docker提起合作被拒绝。

2014注定是一个神奇的一年，2014年6月，谷歌公司突然开源了k8s项目，并且个redgat联手维护，这个项目和2013年docker项目的横空出世一样，改变了整个容器市场的格局，形成了三足鼎立的局面。

 

在容器编排领域k8s需要面对两个方面的压力，docker swarm擅长的是和和docker生态无缝集成，mesos擅长的是大规模集群调度与管理。

后来k8s为什么能胜出呢，他构建出了一个与众不同的服务编排与管理，和监控的生态。还添加了很多容器管理项目，面对这样的竞争优势，docker公司在2016年作出了一个震惊所有人的计划，，为了扩大自己的优势放弃所有的swarm项目，把容器编排和集群管理功能内置到docker项目中，有点孤掷一注的意思，这样使的一个docker项目扩大到一个完整的pass项目的范畴。

而k8s的应对方法是反其道而行之，开始在整个社区退行民主化架构，k8s项目为开发者暴露了可以扩展的插件机制，鼓励用户通过代码的方式介入k8s。这个效果立竿见影。

跟快整个社区催生出了大量的基于k8s的接口的二次创新工作，热度极高的的微服务治理项目istio就是这样诞生的，整个k8s社区空前繁荣，面对k8s越来越强大，docker公司开始承认自己的失败，全面放弃和k8s的竞争，开始商业化转型。

2017年docker公司宣布，内置k8s。容器编排之争落下帷幕。