卢艾飞过去两年，Docker一直充满争议。比如去年年底，K8s宣布不支持Docker。消息一出，大家争先恐后地讨论Docker的替代方案。Colima作为DockerDesktop作为Docker的流行开放替代品，Podman作为Docker的替代品受到了众多开发者和企业的关注。今年，Docker宣布DockerDesktop将向大中型企业用户收费，“再见Docker”的声音再次高涨。从各个方面来看，Docker在技术领先和盈利能力方面已经开始落后。不禁要问，曾经风头正劲的容器化龙头后来怎么样了？容器的兴起将时间倒推了几年。大家一提到Docker，就会把它等同于容器技术。Docker引领容器技术变革的辉煌岁月，至今仍让人激动不已。2013年，CloudFoundry是云服务领域的绝对焦点。以CloudFoundry为核心的PaaS平台服务能力革命席卷了整个云服务领域。与此同时，一批优秀的PaaS平台应运而生，包括SalesforceHeroku、IBMRedHat等。其中一家名为dotCloud的公司也是这场PaaS热潮的一部分。但是在当时的CloudFoundry项目中，容器是最底层，也是最不被关注的部分，所以dotCloud的产品一直没有被关注。为了改变这种被动的现状，dotCloud决定开源自己的容器项目Docker。短短几个月，Docker项目迅速崛起，迅速颠覆了CloudFoundry定义的PaaS平台。那么Doc??ker相比CloudFoundry有哪些决定性的优势呢？这从CloudFoundry的应用程序托管开始。CloudFoundry的核心组件是一套应用程序打包和分发机制。用户只需执行一条命令，即可一键将应用发布到云端。为了支持这样的特性，CloudFoundry实际上会针对不同的语言或框架发布不同的打包器（BuildPack），然后将本地可执行应用程序打包并上传到CloudFoundry，CloudFoundry会派遣合适的代理去下载应用程序,并完成部署。为了保证agent上的服务相互隔离，CloudFoundry会通过Cgroup和Namespace为应用程序提供隔离的“沙盒”运行环境。CloudFoundry的首席产品经理在比较了CloudFoundry和Docker之后，也表示Docker没有黑科技。与CloudFoundry一样，它也依赖于Cgroup和Namespace来创建一个“沙盒”运行环境。那么Docker比CloudFoundry有什么优势呢？答案就在于镜像这种特殊的应用程序打包方式。典型的应用程序运行环境包括代码、依赖项和操作系统。CloudFoundry可以保证代码和依赖一致，但不能保证系统环境。因此，有时本地运行正常，但在云端运行不正常。如果出现问题，很难定位到系统环境。不同之处。而Docker正好解决了这个痛点，通过Image构建Rootfs，完美保证了本地和云端运行环境的一致性。在此基础上，Docker还提供了一个友好的DockerCLI来创建镜像，还提供了一个DockerHub来快速分发镜像，结交同性朋友。在Docker迅速成功后，dotCloud也更名为Docker，Docker成为了容器技术的代言人。在容器云竞争中单纯解决应用打包是不划算的。企业真正需要解决的是应用部署问题。Docker也意识到容器平台能力是成功的关键。2014年，Docker公司迅速发布了Swarm项目，该项目依然保持着Docker友好的命令风格，只需几条命令即可完成多机集群部署。在此基础上，我们不断招人，比如收购了Fig项目（后更名为Compose），以及专门做容器网格的SocketPlane等，来丰富我们的平台能力。此时，Docker在容器领域拥有绝对话语权，Docker的平台化战略实际上已经挑战了其他云服务平台的切身利益，包括谷歌、RedHat等公司。为了改变Docker一统天下的局面，Docker、Google、RedHat等公司联合成立了OCI（OpenContainerInitiative），旨在定义镜像和容器运行时标准，并将标准与Docker项目的实现分开.很显然，Docker不会把精力花在这样一个削弱自己影响力的项目上，所以OCI规范一直进展缓慢。但Google和RedHat并没有坐以待毙，纷纷使出大杀器---Kubernetes。大家联手成立了CNCF基金会。基于Kubernetes项目，在开源基础设施领域成立了一个由厂商主导的独立基金会。平台级社区以同样的方式运作，对抗以Docker为中心的容器商业生态。凭借其强大的设计和RedHat优秀的社区运营，Kubernetes很快催生了极具特色的容器编排和管理生态，并催生了Prometheus、Istio等一批优秀的开源产品。为了应对Kubernetes带来的挑战，Docker正聚焦DockerNative战略，摒弃现有的Swarm项目，将所有容器编排和集群管理功能构建到Docker项目中，这也为未来埋下隐患——-尾巴太大不会掉下来。即便如此，Docker也无法与不断壮大的Kubernetes社区竞争，最终以失败告终。Docker将容器运行时runc项目捐赠给CNCF社区，将Docker项目更名为Moby，交给社区自行维护。拥有Docker的注册商标，将Docker的客户交到自己手中，彻底开始自己的商业运作。Docker在容器云大战中的困境，以Docker的失败而告终。失去云平台制高点后，留给Docker的盈利点已经不多：软件付费私有Hub容器云平台专业技术支持和培训容器云平台市场份额低限制了营收。为了确保盈利，Docker宣布了对DockerHub和DockerDesktop收费的商业决策。有种饮鸩止渴的感觉。从技术角度来看，Kubernetes已经成为容器编排的事实标准，而Container只是整个布局的最底层。OCI规范已经成型，类似容器运行时的containerd已经取代Docker成为大多数托管Kubernetes服务使用的容器运行时。让我们谈谈DockerHub。基本上成熟的云平台都发布了自己的ContainerRegistry，比如AmazonElasticContainerRegistry(ECR)，私有Hub的收费方式还很脆弱。由于设计理念的不同，Docker增加了很多组件来保证友好的用户体验，这是Kubernetes不需要的。另外不支持Kubernetes的CRI规范。从下图可以看出，社区需要维护一个DockerShim项目来桥接KubernetesNode和Docker。一开始，Kubernetes为了接入Docker生态愿意维护这套项目，但随着OCI和CRI规范和产品的成熟，社区失去了继续维护该项目的动力。（图片来源：KubernetesisRemovedDockerSupport，KubernetesisNotRemovedDockerSupport）失去了容器编排的位置，容器标准的话语权逐渐被削弱，再加上饮鸩止渴的收费商业模式，只有靠着优秀的用户体验，Docker真的能留住大家吗？不禁要问，廉颇老了，还能吃饭吗？
