【51CTO.com快译】大家听说过《集装箱战争》吗?这是一部系列纪录片，内容是一支探险者队伍希望夺取拍卖后无人认领的神秘集装箱的故事。之所以有趣，是因为他们必须为之投入大量精力，但却无法事先得知能够得到的是隐藏的宝藏还是一堆垃圾。
颇为讽刺的是，同样的情况其实正在Linux容器(container，亦有集装箱之意)领域上演。
Docker生态系统如今如火如荼，企业软件供应商们纷纷对其表达不满，并积极呼吁开放型容器标准。虽然其部分原因在于Docker 1.12版本中存在一些bug且功能仍有欠缺，但其背后理由绝不仅仅如此。
笔者认为，bug并不是问题，毕竟没有哪款软件能够真正做到零bug。随着时间推移，软件质量必须在持续交付的帮助下得到提升。也正因为如此，有人认为至少在安全角度来讲，永远不要追赶最新版本——稍微落后几个版本并不可耻，反而非常稳妥。
另外公平地讲，Docker 1.12并没有真正给主流用例带来什么破坏。人们对于1.12版本的不满主要源自过高的预期。很明显，预期中的部分功能未能及时上线，再加上少数几个bug，这些对于软件项目来讲并不算什么大事。
因此，笔者认为战争爆发的真正原因只有两个：意识形态与经济利益。
我们首先来看意识形态。当提到“Docker”，我们实际所指的对象有二——Docker容器镜像格式; 负责对该镜像进行实例化并管理相关容器生命周期的docker引擎。
从表面上看，大家完全可以选择其它基础设施工具及框架来支持Docker镜像格式，或者接入该引擎以实现容器运行。
然而Docker公司创始人Solomon Hykes对这种“仅立足于镜像”的定位方式并不满意，其指出Docker引擎之外的全部工具都“只能片面地支持”该镜像格式。听起来镜像与引擎二者拥有密不可分的联系，意味着其它容器执行框架永远无法在效果上与Docker引擎相提并论。这种方式显然有悖Unix的模块化软件组件分离这一指导原则。而Docker 1.12版本高度强调“功能丰富”方向并整合进Swarm编排工具以及DNS路由等功能，这一切无疑引发了更多争议。
在专业人士看来，这一切更像是企业中的客户吸引机制，而非合理的技术正确性与开源社区利益导向。(需要强调的是，Docker软件仍然属于开源项目，目前仍有来自世界地的无数工程师为其提供贡献。)
这就引出了下一议题，经济利益带来的冲突。
短短数年之间，Docker已经成为每家软件厂商都希望参与的火热技术品牌。然而由于Docker品牌被Docker公司牢牢把握，其只能寻求建立自己的名号与技术。
在另一方面，企业软件供应商则围绕着Docker打造各类成果。如今，容器编排/调度领域已经人满为患。谷歌有Kubernetes，红帽、OpenStack基金会与CoreOS都对其表示支持。而Marathon、Nomad、Kontena等其它竞争者亦层出不穷。很明显，内置且易于使用的Swarm模式对其正是一种严重威胁。
CoreOS很可能是第一批公开批评Docker架构及战略决策的群体。这是因为他们发布了rkt——一种竞争性容器化格式。接下来OCI又推出了行业标准化与控制要求，即开放容器倡议。Docker旋即加入此倡议，并向项目代码库内捐赠了其容器格式与runC运行时，旨在加大自身对该项目走向的控制能力。
在笔者看来，这意味着无论谁需要使用标准化、稳定的主干容器技术，都必须围绕runC展开。在此同时，Docker公司将继续保持创新能力与可观的经济收入。
事实上，容器战争这场传奇故事才刚刚拉开序幕。新的厂商会来扰乱市场，并爆发出新的冲突。生活在这个技术理想化时代，亦有众多Docker使用者因不满于其稳定但却沉闷的特性而推出种种fork。这种对灵活性、适应性及弹性的追求无疑又给战争引入了更多变数。
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
