伴随着Docker公司的容器技术生态在云计算市场中站稳了脚跟,围绕着Docker项目进行的各个层次的集成与创新产品,也如雨后春笋般出现在这个新兴市场当中。
而Docker公司,不失时机地发布了Docker Compose、Swarm和Machine“三件套”,在重定义PaaS走出了最关键的一步。
这段时间大量围绕着Docker项目的网络、存储、监控、CI/CD,甚至UI项目纷纷出台,涌现出如Rancher、Tutum这样在开源与商业上均取得了巨大成功的创业公司。
2014~2015年间,容器社区真是热闹非凡。
繁荣背后,更多担忧,即对Docker公司商业化战略的种种顾虑。
Docker项目此时已经成为Docker公司一个商业产品。而开源,只是Docker公司吸引开发者群体的一个重要手段。
不过这么多年来,开源社区的商业化其实都是类似的思路,无非是高不高调、心不心急的问题罢了。
真正令大多数人不满意的是Docker公司在Docker开源项目的发展上,始终保持绝对权威,并在多场合挑战其他玩家(CoreOS、RedHat,谷歌微软)的切身利益。
其实在Docker项目刚刚兴起时
Google也开源了一个在内部使用多年、经历过生产环境验证的Linux容器
1 lmctfy(Let Me Container That For You)
然而,面对Docker项目的强势崛起,这个对用户没那么友好的Google容器项目根本没有招架之力。所以,知难而退的Google公司,向Docker公司表示了合作的愿望:关停这个项目,和Docker公司共同推进一个中立的容器运行时(container runtime)库作为Docker项目的核心依赖。
不过,Docker公司并没有认同这个明显会削弱自己地位的提议,还在不久后,自己发布了一个容器运行时库
2 Libcontainer
这次匆忙的、由一家主导的、并带有战略性考量的重构,成了Libcontainer被社区长期诟病代码可读性差、可维护性不强的一个重要原因。
至此,Docker公司在容器运行时层面上的强硬态度,以及Docker项目在高速迭代中表现出来的不稳定和频繁变更的问题,开始让社区叫苦不迭。
这种情绪在2015年达到了一个小高潮,容器领域的其他几位玩家开始商议“切割”Docker项目的话语权 — 成立一个中立的基金会。
2015年6月22日,由Docker公司牵头,CoreOS、Google、RedHat等公司共同宣布,Docker公司将Libcontainer捐出,并改名为
3 runc
交由一个完全中立的基金会管理,然后以runc为依据,大家共同制定一套容器和镜像的标准和规范。
这套标准和规范,就是
4 OCI( Open Container Initiative )
OCI的提出,意在将容器运行时和镜像的实现从Docker项目中完全剥离出来
- 一方面可以改善Docker公司在容器技术上一家独大的现状
- 另一方面也为其他玩家不依赖于Docker项目构建各自的平台层能力提供了可能
OCI更多是高端玩家出于自身利益一个妥协结果
尽管Docker是OCI的发起者和创始成员,却很少在OCI的技术推进和标准制定等事务上扮演关键角色,也没动力推进这些所谓标准。
这也是OCI组织效率持续低下的根本原因。
眼看着OCI无力改变Docker公司容器领域一家独大现状,Google和RedHat等第二把武器摆上了台面。
Docker之所以不担心OCI威胁,就在于它的Docker项目是容器生态的事实标准,而它所维护的Docker社区也足够庞大。
可是,一旦这场斗争被转移到容器之上的平台层,或者说PaaS层,Docker公司的竞争优势捉襟见肘
在这个领域里,像Google和RedHat这样的成熟公司,都拥有着深厚的技术积累
而像CoreOS这样的创业公司,也拥有像Etcd这样被广泛使用的开源基础设施项目。
可是Docker公司呢?它却只有一个Swarm。
所以这次,Google、RedHat等开源基础设施领域玩家们,发起名为