夫以铜为镜，可以正衣冠；以史为镜，可以知兴替；以人为镜，可以明得失。
我们学习一门新技术是需要时间成本的，我们希望学会以后能用它很久，但有些技术还没等学会，它就死了。还记得在大学的时候，选修里有Flash这门课程，可以做动画片，还能在网页中使用，于是课上课下花了不少时间去学，后来有一天，听说Chrome将不再支持Flash，这让Flash元气大伤，而我除了用Flash给当时的女友做了一个动画外，后来就再也没有用过。现在看来有这时间我去学点别的不好吗？所以啊，还是不能看什么火，看什么热就学什么，毕竟人的时间精力都极度有限，我们学一门技术前应该看看它的发展史，分析下它是干啥的，以后用不用的到？会不会很快被替代？
就算最后我们选错了，我们也思考过了，总比盲目选择要好的多。下面我们就以讲故事的形式来谈谈容器的发展，希望能激发思考，提升学习兴趣。
话说那是某年前的一天，云计算也是刚刚兴起，各大公司、开源社区都在忙着搞 PaaS（Platform as a Service），其中有一个名叫dotCloud的小公司，也置身于这场热潮之中，没有人关注这家默默无闻的小公司，这个公司内部有一个内部项目，用着还不错，于是dotCloud公司说就开源一下让大家用吧，能不能火的谁知道呢，开就完了。果然啊，就有很多人看了这个项目，说这货新瓶装旧酒，底层就是用了存在已久的Namespace和Cgroup技术来做资源隔离和限制，没啥新东西，大家不要在意它！但是几个月后呢，这个项目迅速火了起来，这就是后来大名鼎鼎的Docker，妥妥的diao丝逆袭有没有。
其实Docker的火热不是偶然的，它所使用的Namespace和Cgroup确实不是新技术，但是Docker确拥有一项杀手级的功能，这就是容器镜像,这个功能影响有多大呢？这么说吧，传统的应用上线过程是：开发写代码，运维上测试环境，然后上生产环境，但是有很多时候本地开发环境、测试环境及生产环境都有一些区别，比如软件的版本之类的，这有很多时候会导致程序运行问题，Docker镜像可以理解成一个压缩包，这个包里有完整的操作系统文件和执行程序，用户应用程序依赖包内的这些文件运行即可，不需要依赖宿主机的操作系统，这样一来，就实现了各种环境的统一，再也不用担心环境不一样导致应用起动不了啦！
当然了，发明了容器镜像功能只是Docker火爆的一个原因，对于一个开源项目，想要发展的好是多方面的，比如历史契机（Paas已经深入人心）、活跃的社区（Docker的一个主要定位就是给开发者提供优秀的开发者工具，开发者至高无上！）现在大家都已经知道Docker了，但是确不一定知道dotCloud公司，所以dotCloud干脆把公司名称改为Docker，这样知名度也就上去了。
这时Docker的社区已经非常繁荣了，有很多公司开始给Docker贡献代码，比如RedHat、CoreOS等，这些公司当然也有自己的考量，他们想基于Docker做平台化，简单的说就是搞个大平台，来管理Docker容器，于是CoreOS发布了Fleet容器调度工具，RedHat则有OpenShift，但是Docker现在风光无两啊，你觉的他会甘愿做个小角色？当然不会，它紧接着推出了自己的容器管理平台Swarm，随后又有很多当年耳熟能详的容器管理工具出现，比如说Marathon，一时间真的是百花齐放，大公司都在研究哪个更好，开始给自己看好的项目贡献代码，为后续应用于自己的生产环境做准备，小公司们则在静待吃瓜。
对于Docker开源社区的发展问题上，Docker公司有点一言堂的味道了，Google、Microsoft、RedHat这些大哥们有点说不上话了，对于如此火爆的技术，大哥们要是不能一起玩，你说大哥们能乐意吗？同样，一言堂的作风很容易让人做出差强人意的决策，Google曾想和Docker公司合作推进一个中立的容器运行时（container runtime）库作为 Docker 项目的核心依赖，但是Docker不同意啊，Docker说你们都听我的就行，我来搞个Libcontainer作为运行时库，但是Docker公司当时是突然火爆的一家公司，对于管理、技术上都没有太多积累，所以在战略和技术管理方面都出现了一些问题和分歧，代码的质量也出现了问题。
Google、Microsoft、RedHat等公司一看，就对Docker说了，老弟啊，你这么玩可不行，早晚让你玩坏了，这样吧，咱们搞个中立的基金会，你把Libcontainer捐献出来，你还牵头，我们一起搞，让它发展的更好，顺便改个名字叫RunC吧，根据RunC咱们一起定制一套容器相关的规范，也就是后来的 OCI（ Open Container Initiative ），这套规范就把容器运行时和镜像实现从Docker项目中直接抽出来了，这代表着其它的容器管理平台，不需要依赖Docker了，你自己搞个容器，只要按着OCI标准来搞就行了。这就是想把Docker的权力分一分，但是Docker在容器领域就已经很好了，有繁荣的社区，所以这没有从根本上撼动Docker的地位。
Google一看这家伙，小老D还挺能撑啊，我得给你来点更厉害的，给你来个降维打击。Google有个比较传统的做法，内部系统用的时间长了，觉的该升级换代了，就把当前系统的论文发出来，你比如说hadoop大数据那套，最初的灵感就来自Google发表的论文，这时候Google内部有个系统，也是基于容器编排的，叫borg，在内部已经运行了很多年了，但是对外部来讲还很超前（这里给Google的技术点赞）
，然后Google又说了，咱们一起再成立个基金会: 云原生基金会（CNCF），咱们第一个项目就搞个k8s吧，在borg的基础上来搞，就这样有Google做背书，k8s项目在Github上小星星一路涨，眼看就把Docker自己的Swarm超越了。
CNCF社区一看，好苗头啊，同志们加把劲，我们需要让CNCF社区更繁荣，就还围绕着k8s来，然后CNCF就开始孵化一个个的云原生项目，比如Prometheus等，Docker眼看不敌，做了一个大胆的决定，把Swarm集成到Docker中来，但这无疑会增加Docker的体量和复杂性，这无疑也是一个风险极大的做法，但是最后，大家都知道k8s如今已经成为容器编排的基本事实。
最后，Docker把容器运行时Containerd捐献给了CNCF，自已则专注去做商业化业务，可以说在这场大战中Docker还是战败了，不过也不必担心Docker的未来，它未来可以做一些容器解决方案，技术咨询等业务，相信也会非常不错，看吧，只要你够强，就能和巨头掰掰手腕，不管结局如何，精彩的历史已经书写。
你还知道哪些细节，或者相关小故事，可以和大家一起分享。
