Docker 切出 Moby 背后的真实原因分析

简介:

事件起因

上周 Docker 公司在其技术会议 DockerCon 会议上宣布了新的项目:LinuxKit 和 Moby,一时之间在开发技术圈引起轩然大波,而在本土则是一篇知乎上的回复,刷爆了4月24日早上(周一)的朋友圈,知乎的地址是:对于 Docker 改名 Moby ,大家怎么看? ,其中一个做全球云的匿名用户的回答,一下子拥泵无数,认同、赞许声不绝于耳。大意是 Docker 认怂了,放弃情怀路线,向世俗低头,在赚足了粉丝之后要走欺骗大家的路线,下一个 VMware 就要诞生了等等之类的。

我不敢苟同,我想我应该以一名 开源布道者 的身份,来发表一下我自己的看法。

红帽与 Fedora 社区、项目

在谈 Moby 和 Docker 之前,笔者要和大家先谈谈 Fedora 与 RedHat ,历史总是有相似之处,但也不会完全相同,但总能够通过回顾过去来总结当下,从而发现蛛丝马迹。

时间要退回到2003年,彼时的红帽做了一个很大的决定,不再支持已经发行了将近10年的 Linux 发行版—— RedHat Linux,当时的版本是 RedHat Linux 9,也就是说不会出 RedHat Linux10 版本,而是更改为 RedHat Enterprise Linux 2.1 。除此之外,还进行了纯粹的社区建设,基于社区的发行版,由志愿者驱动的发行版—— Fedora 就这样诞生了。

Fedora 最初的名称叫做 Fedora Core,在发行到第7个版本之后,简称为 Fedora,之后一直沿用至今,目前的版本是 Fedora 25,主要的版本有三个:工作站、云平台、服务器。

Fedora 的 logo 和归属权是属于红帽公司的,但Fedora有着非常成熟的社区化运营和治理,不仅就操作系统而言有明确的项目分工,而且还有特别兴趣小组这样的创新团队。成为 RHEL 重要的软件创新源头,来自全球各地的志愿者,当然也包括红帽公司的员工,为这个全球较流行的 Linux 发行版贡献力量。

红帽虽然是在1993年成立,并在1999年赶上了互联网 .com 时代的浪潮,也成功的 IPO,但是一直在盈利模式上没有很好的突破。直到2003年将自己的商业版和社区版的品牌分离运作之后,才变成到目前为止的开源界独一无二的成功的上市公司,并且最新的季度报表显示,收入超过20亿美元。

在2003的红帽发行版重构品牌之时,也有不服的人站出来直接发展出项目 CentOS,目标就是 RHEL 的社区版,直指红帽的商业发行版RHEL。尽管后来在2014年红帽将 CentOS 收购,但 CentOS 究竟是 RHEL 的助推者还是寄生者,现在还不好下结论。

Docker 的商业化道路

Docker 作为PaaS平台dotCloud的衍生品,以重新包装Linux的容器而风靡开发者圈,完全重新定义了软件的交付方式。自2013年第一个版本发布起,发展非常迅速。不仅吸引了众多IT大鳄的青睐,而且很快成为了Linux容器的生态事实上的标准。

但是,Docker本身的商业化道路一直都备受关注,正当很多基于Docker的创业公司和产品层出不穷,急着变现的时候,比如国内很多基于容器的云公司,如红帽的OpenShiftV3的PaaS平台,以及公有云AWS、Azure、GCE等都似乎利用容器赚了个盆满钵满,然而,很多人开始为Docker公司着急了,害怕他成为当年Sun公司的Java,大家都在赚钱,唯独最初的原创者找不到合理的模式。

最初Docker走的商业化道路是提供安全的Docker镜像仓库和漏洞检查等,然而似乎买账的人并不多。就在前不久,Docker公司将Docker的版本区别为企业版和社区版,这样反而更加引起开发者的不乐意,加上Kubernetes在容器编排的盛行和社区经营的成功,Docker周边的组件如SwarmKit等,正在呈下降趋势。俗语有云:“穷则变,变则通。”我想,过去的都是铺垫,只是时机未到,这不,Docker如此高调的举措,着实是很多人没有想到的。

技术架构诠释

基于开源的战略,技术架构一定是其中一个部分。正如Brook在《设计原本》中所提到的,没有一个合理的技术架构,协作的可能性就会为零。

让我们通过Docker官网上介绍的Moby项目,来回顾一下Docker和Moby的技术发展。

在Docker刚刚从dotCloud的项目中分离出来的时候,一切看起来都是那么的粗糙,在很多人眼里,甚至都不能算是创新,而是旧的技术的一个重新组合,如lxc、cgroup、namespace等,下图非常形象的说明了一切。


82c76e2a8f40dd6bbc99269f52ef65d05676ff12

技术的本质就是在各种组合,在不断进化的过程中,Docker渐渐的发展成为独立的,比如替换掉了LXC,很多原来小的功能,甚至都发展出来相对独立的组件如runc、 HyperKit、VPNKit、SwarmKit、InfraKit、containerd等等。但是这样依然远远不够。

某种程度上,Docker依然是被业务所推动,随着云计算,数字转型时代的到来,IoT、Mobile、机器人、AI等,也随着各种平台的需求,如AWS、Azure、GCP,以及各种操作系统Linux、MacOS、Windows等,Docker不想重复造轮子,这不是一个开源的思路,于是从大众汽车的生产线获得灵感,以生态为目标,将各种组件分离出来,进而满足各种层次的需求。


a7e8f7cb181932c3a43a282220a6a31cd5a6331c

如上图所示,要将协作提到更高的层次,还不是汽车厂那么的“集中和官僚”,于是以技术为主导,设想出Moby项目,Moby更像是一个“乐高积木”,可归纳为:

容器化的组件库(例如:底层的构建、日志处理、卷管理、网络、镜像管理、containerd、SwarmKit等)

框架,用于组装组件到一个独立的容器平台,当然也包括这些组件的构建工具、测试、部署artifacts。

一个参考模型:Moby Origin, 诞生于Docker原来的架构。

解读 Moby 的项目声明

Docker 最初的使命和形式,仍然保持原状,人们可以构建、运行、交付容器。但是Docker本身也在进化,模块化的组件会被不断的独立,如runc、containerd等。而且Containerd也捐赠给了CNCF基金会。

Moby,将以“乐高积木”的形式出现,能够聚合众多的组件,成为一个框架式的试验场地,让容器爱好者来进行各式各样的组合、试验,进而发展和创新。

以Fedora和RHEL作为对比和参照,(尽管不完全一致。)Moby正是大家各种创意的“沙滩”,供容器发烧友和Geek们进行创新和测试,有很好的创意进行第一时间的验证。完全由社区、志愿者驱动,交给了GitHub的开源组织来提供社区的运营,也会组合其它诸如LinuxKit这样的关系紧密的项目。而Docker则渐渐退出激进、狂热等充满创意的阶段,进而开始趋于稳定、安全、企业级应用成为其关键词,目标直指各种上市公司的IT交付基础设施。

按照“社区胜于代码”的思路,Moby还有很长的一段路要走,能够聚集更多的业内爱好者和高手,才是真正的挑战所在。我宁愿相信Docker自己所说的,他们是和整个生态息息相关的:

“if the ecosystem succeeds, we succeed.”

结语

Docker 目前的做法值得所有人尊重。他在不断的探索,不断的尝试,而这就是让时代能够进步的动力和原因所在。他在平衡社区的生态与各方开发者的情感以及自己商业化道路之间复杂微妙的关系。这种努力和尊重,值得开源界敬重。

我们唯一能做的就是希望Docker能够平衡好各方利益,为技术创新走得更远。

本文来自开源中国社区 [http://www.oschina.net]

目录
相关文章
|
4月前
|
SQL Linux Go
docker镜像分析利器之dive
docker镜像分析利器之dive
84 0
|
6月前
|
运维 安全 Docker
Docker 网络模型:多角度分析容器网络的原理与应用
Docker 网络模型:多角度分析容器网络的原理与应用
55 0
|
JSON 监控 关系型数据库
Docker 容器日志分析
Docker 容器日志分析
390 0
|
Kubernetes 监控 Java
【JVM故障问题排查心得】「内存诊断系列」Docker容器经常被kill掉,k8s中该节点的pod也被驱赶,怎么分析?
【JVM故障问题排查心得】「内存诊断系列」Docker容器经常被kill掉,k8s中该节点的pod也被驱赶,怎么分析?
653 0
【JVM故障问题排查心得】「内存诊断系列」Docker容器经常被kill掉,k8s中该节点的pod也被驱赶,怎么分析?
|
4月前
|
运维 监控 数据可视化
日志管理:收集和分析Docker容器日志
容器化技术的普及使得应用的部署和管理更加便捷,但随之而来的挑战之一是有效地管理和分析容器产生的大量日志。本文将深入探讨Docker容器日志管理的重要性,介绍常用的日志收集工具,以及如何分析和利用这些日志数据,提供更为丰富和实际的示例代码,帮助大家更好地理解和应用日志管理的关键技术。
|
1月前
|
Kubernetes Go 开发者
Go语言与Docker容器结合的实践应用与案例分析
【2月更文挑战第23天】本文通过分析实际案例,探讨了Go语言与Docker容器技术结合的实践应用。通过详细阐述Go语言在容器化环境中的开发优势,以及Docker容器技术在Go应用部署中的重要作用,本文旨在为读者提供Go语言与Docker容器结合的具体实现方法和实际应用场景。
|
8月前
|
自然语言处理 数据可视化 关系型数据库
SolidUI社区-独立部署 和 Docker 通信分析
SolidUI社区-独立部署 和 Docker 通信分析
62 0
|
4月前
|
并行计算 Linux 计算机视觉
DeepFace【部署 04】轻量级人脸识别和面部属性分析框架deepface使用Docker部署CPU+GPU两个版本及cuDNN安装
DeepFace【部署 04】轻量级人脸识别和面部属性分析框架deepface使用Docker部署CPU+GPU两个版本及cuDNN安装
188 0
|
4月前
|
Linux API 计算机视觉
DeepFace【部署 03】轻量级人脸识别和面部属性分析框架deepface在Linux环境下服务部署(conda虚拟环境+docker)
DeepFace【部署 03】轻量级人脸识别和面部属性分析框架deepface在Linux环境下服务部署(conda虚拟环境+docker)
76 0
|
4月前
|
Kubernetes Shell API
DeepFace【部署 02】轻量级人脸识别和面部属性分析框架(实时分析+API+Docker部署+命令行接口)
DeepFace【部署 02】轻量级人脸识别和面部属性分析框架(实时分析+API+Docker部署+命令行接口)
91 0