本文转载自DBAplus社群。作者：周晖，Pivotal大中华区云计算首席架构师，有着丰富的PaaS云实际建设经验，负责过国内某知名银行已经生产上线一年的PaaS云的架构设计和部分功能的实现，参与过某超算PaaS、某超市电商PaaS、某电力PaaS等项目的建设。
从一场容器的撕逼战开始说起
从2016年7月底开始，Google Kubernetes布道师 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上发生了一场撕逼大战，主题是要不要用RunC或其他容器来取代Docker引擎以及OCI的意义。
首先是Google的Kelsey挑事，说：“很多平台都可以跑Docker镜像，已经不再需要Docker Daemon了。哪个会成功呢？”
Docker CTO Solomon马上接招：“其他平台跑Docker镜像是假的，其中只有90%能正常工作，其余10%则随时可能会出问题。而且Docker还在演进中。”“所以嘛，声称‘可以跑Docker镜像’的都是在撒谎。”
Kelsey Hightower反讽：“好吧，那我们就没必要再提支持Docker了。我们实际支持的只是Docker的容器格式”，“Docker拥有创建和分发镜像的最佳工作流，而运行时，还是留给它的竞争者们吧。”
所罗门继续强调Docker的不兼容性：“这些都是不完整的、不兼容的支持”，“他们也并不支持镜像格式，镜像的很多信息都会丢失”。
后来，所罗门急眼了，说“OCI就是个伪标准”。
此言一出，惊诧四方，因为OCI有50多家厂商参与，而且Docker还是重要贡献者，有说“标准不是一个人可以决定对错的”，有反讽的 “我相信工程师们乐于听到他们创始人说他们做的工作是假货”。
Kubernetes的老大Tim Hockin直接就说“不爽你就走，不要假装参与”。
所罗门不得不改口说“OCI标准的初衷是好的，只可惜扩展太早，我不认同就得走？”
有人随即反驳“只有你一个人说扩展的太早，这是明显的利益投射”。
所罗门还嘴硬“就因为我是唯一的不认同者，那我就必须离开？”
Kelsey随后则直点主题，“有两个问题在台面上，一是容器需不需要标准化，二是需不需要由Docker来领导这个标准化的工作？”
Kelsey再以嘲讽的口吻自问自答“如果是Docker来回答这些问题，对第一个肯定是说不，那干脆对第二个问题也同样说不吧，这可不是对和错的问题”。
因为事关OCI，Docker现在这么鄙视RunC，OCI不得点出Docker你也是参与者就别闹了， “Docker参与在OCI运行时和镜像规范，也参与了每周的开发会议”。
Kelsey乘胜追击，代表业界吐了个槽，“我一直相信Docker会给容器带来很多，但是我真的担心一个人想控制的太多”。Docker公司的控制欲早成为人们的吐槽点，什么都想做，把整个生态圈其他的参与者逼到墙角去了。
看业界大佬撕逼，感觉和咋人民群众撕逼没太大差别。所罗门的撕逼技巧明显略逊一筹，有点像祥林嫂反复说“其他容器就是和Docker不兼容，包括RunC”，但是没说出个哪里不兼容的道道。
容器撕逼之争反应了容器生态面临的问题
我们来总结这次著名的撕逼事件的来龙去脉，这会成为容器界一个关键的历史转折事件。容器之争始实际上是很早之前就起源于Docker生态面临的问题。
1. Docker商标的注册围剿了容器生态圈
从表面上看，是容器标准之争，其实，反应的是赤裸裸的利益问题。Docker从容器开始，在获得社区的热烈响应之后，就进入了圈地过程，而且第一招圈地就非常凶悍，把公司从dotCloud改名为Docker，然后注册Docker商标，商标意味着当其他公司使用未经Docker社区许可的补丁、代码或软件包的时候时可能面临法律责任。这种情况下，一个公司可能因为补丁尚未经过Docker公司许可，抑或尚未被合并到项目中，而不能为客户提供技术支持。
这不只是法务上的圈地，对于很多采用Docker名字的，Docker公司给予了实际行动—口头警告（谁叫Docker是人家注册的名字呢，就好比weibo.com就是微博），包括你建一个群名不加修饰限定的叫Docker，或是你要写本书，不加修饰的叫DockerXXX，都容易受到Docker的警告。从法务上看这确实也属于侵权，就看Docker要不要告你。
其后果就是第三方Docker生态厂商被迫忍受Docker公司任何对该开源项目作出的决定，在问题出现的时候等待Docker公司的补丁。最好的结果与Docker达成某种协议，由Docker公司来保证提供稳定的发行版本。那Docker的生态公司就沦为Docker公司的代理商了。
2. Docker携容器引擎优势进入容器集群管理，挤压了容器生态圈的其他厂商生存空间
如果只是口头撕逼，那大伙儿看看热闹就可以了，事实上这涉及到巨大的利益和整体生态环境的分歧。
在Docker获得广泛关注以后，就利用Docker容器的广泛性优势来挤压生态圈其他伙伴的生存空间。直接把Swarm内置在Docker中。和当年的Microsoft通过Windows捆绑IE来打击NetScape有异曲同工之妙。
Docker公司原来只在容器领域发展，Kubernetes/Mesos等做容器集群管理，属于CaaS（Container as a Service），相互补充，互不竞争。等Docker容器被广泛关注以后，Docker进入容器编排市场，收购了相关的技术以后推出Swarm的容器集群管理，从容器进入CaaS市场。2016年7月发布的Docker 1.12把Swarm内置到Docker中去了，Docker Swarm作为容器集群管理软件，内置在Docker中，几乎就是Windows捆绑浏览器IE的模式，这就是用不平等的市场优势打击了Google的Kubernetes和Mesos等，Google也不是吃素的，所以7月底马上就是和Docker CTO口头开撕。
对于Docker生态圈的集群管理软件Kubernetes和Mesos等来说，不但是不平等的竞争，最关键的是在容器生态圈最能带来商业价值的就是容器集群管理，单单容器本身并没有太多的商业价值，容器没有集群管理是很难进入企业运行环境的。因为容器的直接商业价值并不大，CaaS厂商也没有自己做容器。容器用于生产系统，就必须有容器的集群管理，而Kubernetes和Mesos已经进入了这个商业领域并且取得了一定的优势。现在Docker进入这个领域，就直接和容器集群管理的公司竞争，但Docker又是必须进入这个领域，如果不进入这个领域，很难取得商业成功， Docker本身又经过多轮风投，风投给Docker带来了巨大的盈利压力，如果久久不能盈利，那风头的脸色不会那么好看了。
如果是公平竞争还好，比如Docker单独发布Swarm的Docker集群管理，但是Docker直接把Swarm内置到Docker中去，安装部署Docker就带了Swarm，而Swarm的很多功能和Kubernetes和Mesos是重叠的，Kubernetes和Mesos再用Docker就显得功能有大量重叠，而且带来了系统的复杂性和不稳定性。
Docker的问题——业界对Docker的吐槽
在Google和Docker口水战之后，业界对Docker的吐槽越来越多，主要包括以下几点：
1. Docker向后兼容性问题
Docker被业界诟病最多的就是后向兼容性，Docker的新版本更关注的是革新性，而不是兼容性，但是，对于一个生产系统来说，后向兼容性至关重要，没有后向兼容性，意味着每次Docker升级都带来巨大的风险。
这也和Docker的企业文化有关，Docker更倾向于采纳新技术，实现突破性的功能，这是典型的初创公司的企业文化，不断的追加新功能，而不考虑企业级特性，更不考虑后向兼容的束缚。这个好处是能在个人粉丝中取得共鸣，这也是Docker快速流行的一个重要原因。任何特征都可能是双刃剑，这种企业文化并不适合企业级，不考虑生产运行的可用性，对企业级应用来说可能是灾难性的。
我们看看业界人士是怎么说的：“Docker不断地破坏向后的兼容性”，RackN公司的CEO Rob Hirschfeld说。RackN公司的应用程序生命周期管理平台同时使用和提供了Docker组件，因此对后端的改动将会对其支持的客户的业务造成影响。
“Docker将Docker Engine用作一个产品，而不是一个社区用来构建自有服务的组件”，Hirschfeld指责道。这种基于产品的策略意味着使用者被逼着在Docker发布新的革新特性或者合并新的组件（如Swarm）的时候去修复其破坏的向后兼容的问题。
“尽管我们会使用这些发布的特性，然而这些改动会带来一系列与稳定性、版本、迁移和后端兼容相关的问题”。
Bob Wise，一名三星SDS云工程师，也同样呼吁Docker放慢其容器创新的脚步，该公司同样提供了基于云的容器相关支持服务。
“如果你的团队在深度使用Kubernetes、Mesos或Cloud Foundry，你需要一个稳定、简单、无奇的容器实现方案，仅有最少的基本功能，由社区协商镜像的创建、命名和发布”，Wise的一篇博客中写道。“你需要使用每个都人都在使用的一个相同的、简单的、无奇的容器实现方案。作为一个社区，我们需要放缓对于基本构建组件的变更速度。唯有稳定性才能让构建其上的系统蓬勃发展。”
2. Docker容器在企业级方面还有待提高
Docker虽然一直宣称Production Ready，但是在实际的生产系统中同样受到不少诟病。
看看业界人士的说法：
Apcera技术产品经理 Phillip Tribble在个人博客中，以一种外交辞令的口吻，让Docker不要再把其新推出的特性鼓吹成一个完工的企业级可用的产品。Tribble写道：“让互联网或者大会充斥着营销材料，宣扬各种令人振奋的新特性，但实际上却不如所说那样能用，不是一个明智的做法”，Apcera的商业模式一部分是基于提供Docker容器的支持。
Tribble的帖子引发了其他人在Hacker News上表达他们的Docker经历，包括一些新版本带来的让人伤心的bug。一位读者谈到一天中启动70,000到90,000个容器，约9%左右的会因为“各种Docker bug”遇到问题，这个比例最近的一次升级后下降到了4%。
但也有一些人在称赞Docker的稳定性，“我们一直在生产中使用Docker约3年了，还没有发现什么大的问题”，另一外读者评论说，“它将一些很炫的Linux内核特性用简洁的方式封装了起来”。
当然也有不少Docker的支持者认为Docker公司的软件是稳定的。同一个产品，在不同的客户有截然相反的反应说明有的用的好，有的用的碰到不少问题，在不同的环境下缺乏一致性，这也是企业生产系统的大忌。
3. Docker捞过界了，越过了红帽的操作系统界限？
哪些功能应该有Docker来实现，哪些功能应该由底层操作系统或者技术栈中的其他组件来负责处理？
在今年的很多会议上，包括 LinuxCon North America 2016，红帽工程师 Dan Walsh 说红帽陷入了困境，一方面客户越来越多的使用 systemd 来初始化Linux系统，而另一方面Docker似乎不愿使用systemd，取而代之使用Docker Daemon来提供初始化，服务激活，安全和容器日志的相关功能。
“在过去的三年里，我们一直试图使systemd和Docker更好的整合，而我却发现，两个领导人都非常强烈的坚持己见”，Walsh说，两个领导人指 Hykes和systemd的创造者-Lennart Poettering
“所以，当机器的时候，谁来负责启动系统服务，是systemd还是Docker？”Walsh问到。一个拙劣的系统实现可能会导致systemd和Docker互相冲突。
红帽为自己的客户维护着自己的Docker版本分支，红帽分支中的补丁Docker有一天可能会合并，或者永远不。红帽也冒着巨大的风险，红帽的客户也冒着巨大的风险。所以红帽对Docker的支持其实远不如Ubuntu,因为Docker已经侵入到OS的领域了。
即使是面对以上种种吐槽，Docker也不打算折中一下，甚至也不打算照顾这些意见，而是继续我行我素。
