Docker 终失 C 位，开源少年缘何黑化

作者 | 马超

出品 | CSDN（ID：CSDNnews）

开源真是火了，近些年成功的IT项目像TensorFlow、RocketMQ、TDEngine都是开源项目，而且这种火爆还出了圈，连带着RISC-V这种准开源的芯片也成为了各方争抢的香饽饽。但是如果仔细观察这一片开源火爆的背后其实也有不少隐忧，由于开源只是一种松散、开放的合作方式，这种合作方式往往能够带来人们意想不到的高价值产出，但由于目前主流的开源协议往往没有对于后续价值分配做出严格约定，这也就造成了诸如“某大厂上开源耻辱墙”、“开发者上门要索要代码”的闹剧频频出现，但这些小纷争和开源巨大的利益蛋糕比起来都是小场面，目前开源界的三大战役主要是Dockers vs k8s、红帽Linux vs Cent OS以及亚马逊 vs Elastic，而这其中Docker的发展轨迹最为典型，也最值得我们思考。

Dockers Desktop收费如饮鸩止渴，加快与k8s的分手历程

近期，Docker 公司更新了旗下产品的订阅策略，其中最显著的变化是Docker Desktop条款的修改。Docker Desktop 对于同时满足雇员少于 250 人，年收入少于 1000 万美元的小型企业、个人、教育和非商业性开源项目仍然免费。但是大中型企业则需要它需要付费了，价格每个用户每月 5 美元起。

虽然收费条款有5个月的宽限，但是而对不断商业化的Docker，开源替代产品也开始跃跃欲试，比如像Podman UI、lima都是不错的选择。而最令人唏嘘的是Docker这样一位开源界的三好学生，为什么会有如此之大的转变。

Docker-曾经的屠龙少年

天下武功唯快不破，在云计算的江湖从虚拟机到容器，再到Serverless莫不如此。十年前OpenStack的发布让云计算正式进入了虚拟机的IaaS时代，OpenStack凭借其开源、开放的特性，使得私有云的创建门槛大幅度降低，理论上讲任何掌握了OpenStack开发能力的企业都可以自行创建和提供云计算服务。

当时的云计算，本质上都是基于虚拟机的，OpenStack可以将一些性能强劲的物理服务器，拆分成若干个虚拟机，提供给用户使用，但虚拟机还是太重了。即使是飞天集群，新增部署虚拟机的时间也是以分钟来计的。但是互联网上的机会往往转瞬即逝，分钟级的等待对于用户来讲就是不能忍受的煎熬，因此瘦身版的虚拟机也就是容器开始走入了大家的视野。

通俗的讲，容器就是基建狂魔版的云平台，虽然传统的基建技术安全性更高，稳定性也更好，但是从头修路、盖房、装修成本太高时间也太长，而容器本质上是一个最小运行环境的镜像，只要给点阳光就能野蛮生长，而且用完以后想拆也很方便，是应对云时代流量冲击的神器。目前Docker几乎已经成了容器的代名词，每个网民都接受过由Docker提供的服务，IT人在日常工作中肯定都接触过Docker，Docker作为容器技术的始祖，以一个憨态可掬的小鲸鱼形象出现，在刚刚出场之际就将Vmware旗下的Paas平台-Cloud Foundry斩于马下。

2013年开始，云计算的PaaS大幕开启。在PaaS时代，云计算的最小使用单位从虚拟机变成容器。最早出现流行开来的PaaS平台是由Vmware创立的CloudFoundry。2012年在帕特.基辛格正式接手Vmware以后，就开始在PaaS方向发力，Cloud Foundry正是基辛格亲手打造出来的拳头产品，通过应用托管功能。开发者只需要通过一条简单的命令，就可以将整个项目打包，上传到Cloud Foundry，而Cloud foundry主机集群中，找到满足用户需求鹤机，通过容器化技术，解压并运行用户的项目包，并快速对外提供服务。令人感叹的是历史总是这样的对称美，Cloud Foundry在被Docker打败之后，基辛格回归英特尔推出的首款拳头产品至强三代Ice Lake有一款专门针对docker的增加型号-8352v，这个型号在高密度容器部署方面有奇效，这段往事读者可以参考前文《溢价5倍欲将Sifive收入麾下，英特尔的绝地反击战》、《超异构时代“炼金术”，开发者表示“惊艳”》这里不加赘述了。

除了基本的容器功能以外，Cloud Foundry还提供应用分发、监控，标准化灾备体系等等服务，Cloud Foundry将程序员从繁重的运维任务中解放出来，让开发者不需要再去关心运行平台的资源使用状况。但是Cloud Foundry并没有把工作做到极致，其打包功能一直为外界所诟病。开发者甚至要为每个应用版本应用打一个包，其带来的调试成本之高令人咋舌，甚至有人抱怨在Cloud Foundry所花费的调试时间远远高于开发一款新的应用。

Build once，Run anywhere这句响亮的口号就是Docker打败Cloud Foundry的最大秘决， Docker与Cloud Foundry相比其底层技术都是namespace和cgroups，但是Docker很好的考虑了应用打包的一致性与复用性问题，并提出了镜像这种创新式的解决方案，完全可以做到三分钟部署一个Nginx集群的效果，正是这种对程序员的友好特性，让Docker成功取代Cloud Foundry成为当之无愧的C位。

痛失标准话语权，Docker埋下隐忧

Docker成为C位后，巨头们也看到了容器方面的商机，CoreOS推出了Rocket容器，Google也推出了lmctfy容器，但是面对简洁易用的Docker，即便是开源界无往不利的Google也败下阵来，推出不久之后lmctfy容器项目就被关停，
幸福来得太快也让Docker有点飘了，在得到大笔融资之后Docker公司开始了疯狂的买买买，不过Docker之前一直是靠开源社区的力量发展壮大的，靠收购打造出的容器三件套：DockerCompose、Docker Swarm以及DockerMachine明显有点水土不服。不过这倒是影响不大，在有了容器三件套之后Docker正式把公司的名字由原来的dotCloud改名为Docker，并且将Docker注册成了商标全面开启商业化之路。

这一系列的动作基本宣告了之前的开源少年已经开始了商业化的转身，这也就意味着，未来云厂商要容器就要向Docker公司支付授权费用，这一系列的动作让容器领域的众多玩家对于Docker产生了警惕，过旧暴露的商业化意图，让云厂商们感到自身利益受到威胁，Docker没落的种子就此埋下。

2015年，Docker在同行巨大的压力下，他们牵头成立了OCI（Open Container Initiative）基金会，并将自己的容器运行时LibContainer改名为RunC捐赠给OCI，由OCI与容器各方共同制定容器和镜像的标准和规范。但是当时的Docker基本没怎么把OCI放在眼里，而且凭借自身的用户优势对于对于标准的制定也是漠不关心。现在回顾起来放弃标准制订的话语权，也是后来K8S有勇气和Docker说再见的主要原因，虽然OCI在Docker的缺位下发展缓慢，但接下来出场的CNCF（Cloud Native Computing Foundation）基金会却是个真正的狠角色，随着CNCF的出现，Kubernetes也就是K8S终于登场了。

君以此始，必以此终，Docker终失C位

K8S是Google在2014开源的一款容器编排项目，一开始K8S只算是一个Google一个人参与的独角戏，但CNCF带来的社区力量改变了这一切，由于这个时候Docker已经在商业化的道路上一去不返了，不久以后K8S社区就开始和Docker分庭抗礼了，而且逐渐有后来者居上的趋势，基于K8S的微服务等新兴技术框架迅速流行开来，最终使得以K8S为代表的容器编排平台成为了云原生时代的C位。面对CNCF的迅速发展壮大，Docker不得已将自己的Containerd捐赠给了CNCF，并且在2017年10月在Docker企业版中默认内置K8S平台。

如果说Docker打败Cloud Foundry依靠的是简洁、简单的微创新，那么K8S对于Docker就是降维打击了，Docker Swarm编排工作只是站在容器视角处理问题，而站在K8S的角度上，容器只是一个运行时的环境，Pod和Service才是K8S编排建模中所考虑的重点，只要符合标准的容器运行时都可以做为Pod进行编排，也就是说K8S对于所有容器一视同仁，用户是否用Docker根本无所谓。在取得优势身位以后，K8S果断开始了去Docker化的动作，在去年年底，CNCF官宣在K8S的1.20版本中Docker能够正常使用，但是会有警告提示，而1.22版本以后，则移除Docker的支持。这其中最大的影响那些用到Docker API的应用都将不能在K8S平台上运行了。

正如刚刚所说Docker在如日中天的时候对于运行时的标准漠不关心，这也使得很多Docker的增强功能是由Docker Shim组件提供的专属API来完成的，但是Docker Shim并不属于标准的容器运行时，这也就意味着K8S甩掉Docker时根本没有什么太大的负担，而且Docker目前在商业化道路上与CNCF社区渐行渐远，K8S目前作为云原生时代的C位，完全没必要为企业版的Docker去背书。

目前DockerDesktop企业版收费的做法并不是一个明智之举，以目前Docker的江湖地位，各种开源替代产品比比皆是，商业化的动作只会加快他们与开源社区的分手历程。不过拿了人的总是手短，接受融资就要受制于资本，Docker的历程在开源界也算典型，比如Red Hat在被IBM收购以后就停掉了免费版的Cent OS项目，如何平衡免费、开放的理念与商业化利益之间的关系，是整个IT界都需要仔细考虑的问题。