<p>一些Docker生态系统的厂商和最终用户正在进行一场从Docker分割出去的讨论。在表达各种对Docker公司在Docker Engine上管理的失望背后，这些技术专家和公司实际上是在探索如何解决在支持企业级的Dokcer部署中遇到的各种烦心问题。</p>    <p>在诸多正在考虑的选项之中，包括可能会将整个开源的Docker Engine一起重起炉灶( <em>fork</em> )。据一些接近讨论的人士透露，相关代表来自Red Hat、Google、CoreOS、华为和两家大量使用Docker的客户。</p>    <p>Red Hat和CoreOS的发言人否认了一切与Docker讨论相关的消息。Docker公司拒绝公开就此置评。Google和华为截止发文前也尚未回应置评请求。</p>    <p>这是对容器生态系统影响深远的时刻。这些技术专家和公司没有任何一方希望采取fork的方式，但同时他们也对Docker的代码库稳定性不足表达了各自的忧虑，因为这可能会在生产环境下基于Docker构建附加服务或者向客户提供技术支持的时候招致各种麻烦。</p>    <p>除此之外，许多参与分割讨论的公司也是使用容器技术来建立大规模分布式系统的公司，Docker公司最近推出的内置编排功能可能会被这些公司视为自家编排产品的威胁，这些产品都几乎基于Google的Kubernetes。</p>    <p>“目前发生的这件事情，如果处理不得当，会让让容器生态系统支零破碎，并导致单个的容器再无可能适配多种目标运行时环境。” 一位Hacker News上的观察员指出。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/ceb1e1f836b6285b95d70683ee9f11db.jpg"></p>    <p style="text-align: center;"><sub>Docker的话题仍然在StackOverflow中处于领先地位，但是 Kubernetes的势头正在上升。</sub></p>    <h2><strong>一个企业级的问题？</strong></h2>    <p>一个我们在Docker生态系统中反复听到的问题是，Docker采取的激进发布安计划时常让第三方的系统提供者和他们的客户发生不快。</p>    <p>“Docker不断地破坏向后的兼容性”，RackN公司的CEO、Kubernetes社区的带头人 Rob Hirschfeld（兼TNS不定时的贡献者）说。他此前并未参与此次分割相关讨论中。RackN公司的应用程序生命周期管理平台同时使用和提供了Docker组件，因此对后端的改动将会对其支持的客户的业务造成影响。</p>    <p>“Docker将Docker Engine用作一个产品，而不是一个社区用来构建自有服务的组件”，Hirschfeld指责道。这种基于产品的策略意味着使用者被逼着在Docker发布新的革新特性或者合并新的组件（如Swarm）的时候去修复其破坏的向后兼容的问题。</p>    <p>“尽管我们会使用这些发布的特性，然而这些改动会带来一系列与稳定性、版本、迁移和后端兼容相关的问题”。</p>    <p>在上周之前，对Docker的不满议论主要都是私下的。但是现在这种议论进入到公共论坛。如谷歌Kubernetes布道师 Craig McLuckie 的推特博文：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/ad81ae90dc6ab48f625440d398a6b37a.jpg"></p>    <p><sub>推文 1：Docker公司必须要容许革新和获利（它们已经做出了了不起的事情），但现在我们需要无聊的内核基础设施。<br> 推文 2：现在真的是容器运行时和格式的标准超越（现有）OCI的范围出现的时候了。</sub></p>    <p>在Docker公司最近将Docker Swarm纳入Docker1.12 后，长期压抑的沮丧达到了顶点。有了Swarm后，Docker Engine能让用户使用熟悉的用来操作Docker的命令行结构和语法，无需借助额外的软件即可管理复杂的容器应用。Docker的编排功能是可选的，他们必须由用户激活 。然而选择不启用可能会在之后带来向后向兼容性问题。</p>    <p>在此之前这些人们熟知编排功能只能通过第三方工具，如Google开源的Kubernetes，来提供。</p>    <p>尽管Google不直接销售企业级容器编排软件，但它的开源编排系统的的确确让谷歌很快驶上了Google Cloud Platform容器服务的高速公路。其他公司，如CoreOS和Apprenda， 也提供Kubernetes的商业支持版本。华为也正在推出了基于Kubernetes的容器引擎（http://thenewstack.io/huawei-launches-kubernetes-based-container-engine/）。</p>    <p>因此，毫不奇怪，所有这些各方都希望将话题从容器转移到容器编排上。</p>    <p>Bob Wise，一名三星SDS云工程师，作为该公司参与Kubernetes的主导人员，也曾同样呼吁Docker放慢其容器创新的脚步。三星电子正在收购Joyent的过程中，该公司同样提供了基于云的容器相关支持服务。</p>    <p>“如果你的团队在深度使用Kubernetes、Mesos或Cloud Foundry，你需要一个稳定、简单、无奇的容器实现方案，仅有最少的基本功能，由社区协商镜像的创建、命名和发布”，Wise在上周的一篇博客中写道。“你需要使用每个都人都在使用的一个相同的、简单的、无奇的容器实现方案。作为一个社区，我们需要放缓对于基本构建组件的变更速度。唯有稳定性才能让构建其上的系统蓬勃发展。”</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/f672fb11450c1be394663c5310418054.jpg"></p>    <p><sub>推文：@countspongebob 来到了这个话题中，也想谈点Docker稳定性的事情。到了fork的时候了吗？</sub></p>    <p>同样，Apcera技术产品经理 Phillip Tribble在个人博客（http://www.linux-toys.com/?p=684）中，以一种极具外交辞令的口吻，让Docker不要再把其新推出的特性鼓吹成一个完工的企业级可用的产品。“让互联网或者大会充斥着营销材料，宣扬各种令人振奋的新特性，但实际上却不如所说那样能用，不是一个明智的做法” ，Tribble写道。</p>    <p>Apcera的商业模式一部分是基于提供Docker容器的支持上的。</p>    <p>Tribble的帖子引发了其他人在Hacker News上表达他们的Docker经历（https://news.ycombinator.com/item?id=12364123），包括一些新版本带来的让人伤心的bug。一位读者谈到一天中启动70,000到90,000个容器，约9%左右的会因为“各种Docker bug”遇到问题，这个比例最近的一次升级后下降到了4%。</p>    <p>但也有一些人在称赞Docker的稳定性，“我们一直在生产中使用Docker约3年了，还没有发现什么大的问题”，另一外读者评论说，“它将一些很炫的Linux内核特性用简洁的方式封装了起来”。</p>    <p>事实上，Docker确实有大量的支持者认为Docker公司的软件是稳定的。Docker工程师在吹捧公司技术实力雄厚方面自然也是比谁都快的。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/f7e61a54d6f808e869c4e27eb9832dd6.jpg"></p>    <p>不管什么情况，Docker似乎不会照顾它的潜在对手的心情而起意扼杀自己的革新的，就像最近一次在推ter上Google Kubernetes布道师 Kelsey Hightower 和Docker的CTO Solomon Hykes 关于OCI镜像和运行时标准应该在基于Docker容器栈的标准化过程中扮演何种角色的争执中所显示的那样。</p>    <p>OCI成立的要旨中提供的正是Wise等人呼吁的：无奇的、标准化的容器技术。</p>    <p>然而，Hykes提出OCI对第三方提供商有用性程度的质疑。Hykes指出，那些声称不需要Docker Daemon（假设通过runC运行时引擎） 也可以提供对Docker容器完全支持的提供商，事实上仅仅Docker提供了拥有Docker 90%特性的“伪支持”。</p>    <p>“我知道的情况是，Docker发展很快，因此那些声称‘支持Docker’的产品都是谎言”，Hykes写到。而在另一篇推文中，Hykes甚至有些事态，屑称OCI镜像是“伪标准”。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/432d4e7f18c3cbe321924bdad22d7530.jpg"></p>    <p><sub>推文：看看这些讨论，告诉我凭什么Docker值得作为一个开放容器标准的管家？</sub></p>    <p>该问题因为Docker公司拥有Docker商标而进一步加剧。商标意味着当公司使用未经Docker社区许可的补丁、代码或软件包的时候时可能面临法律责任。这种情况下，一个公司可能因为补丁尚未经过Docker公司许可，抑或尚未被合并到项目中，而无法为客户客户提供技术支持。</p>    <p>其结局：第三方供应商被迫忍受Docker公司任何对该开源项目作出的决定，在问题出现的时候等待Docker公司的补丁。最好的结果与Docker达成某种协议，保证提供稳定的发行版本。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8478f4c73ed133a2f30a01528a8e50a5.jpg"></p>    <p><sub>推文：某一方的特性是另一方的累赘 > 容器运行时的fork（Docker的！）正在酝酿，因为生态系统需要一个稳定且轻型的构建块。</sub></p>    <p>另外一个存在的问题是，哪些功能应该有Docker来实现，哪些功能应该由底层操作系统或者技术栈中的其他组件来负责处理。</p>    <p>另外一家使用Docke，但是也与Docker竞争，的公司是Red Hat。在今年的很多会议上，包括 LinuxCon North America 2016（http://thenewstack.io/tag/linuxcon-north-america-2016/），红帽工程师 Dan Walsh 描述说红帽成陷入了困境，一方面客户越来越多的使用 systemd 来初始化Linux系统，而另一方面Docker似乎不愿使用systemd，取而代之使用Docker Daemon来提供初始化，服务激活，安全和容器日志的相关功能。</p>    <p>“在过去的三年里，我们一直试图使systemd和Docker更好的整合，而我却发现，两个领导人都非常强烈的坚持己见”，Walsh说，两个领导人指 Hykes和systemd的创造者，现Red Hat员工——Lennart Poettering（https://github.com/poettering）。</p>    <p>“所以，当机器的时候，谁来负责启动系统服务，是systemd还是Docker？”Walsh问到。一个拙劣的系统实现可能会导致systemd和Docker互相冲突。</p>    <p>红帽为自己的客户维护着自己的Docker版本分支，包含着的补丁Docker有一天可能会合并，或者永远不。</p>    <h2><strong>可选的方案</strong></h2>    <p>时间会告诉我们这些非正式言论是否会带来更合作化的努力。有的方案是能满足各方的。例如，可能会有一个通过OCI管理的、稳定Docker镜像格式版本和运行时环境。这将使生态系统的参与者拥有稳定的组件，同时让Docker继续开发自己的Docker Engine。如果是这种情形，OCI运行时将是一个Docker的分支。</p>    <p>但如果生态系统内的这些公司想和Docker完全分割开来，那就意味一个完完整整的fork，使用不同的名称，并需要一个新的小组来管理所有事宜。如CoreOS， 提供了另一种“无守护进程”的容器技术，叫rkt，然而它目前尚未得到市场足够多的目光，至少没法和Docker的成功相比。</p>    <p>这是一片新的领地，充分显示出市场的快速成熟速度和利益博弈。从政治和经济的观点来探究容器生态系统，对于帮助理解社区的技术方向是比较重要的。特别是当你面对Docker和容器生态系统深深的裂痕，以及目前这场围绕着是否需要创建一个Docker的分支的大讨论的时候，这一点尤其适用。如果没有其他可选方案，可能只有创建一个稳定的替代品作为标准内核，然后在其基础上构建能保证终端用户稳定的服务和产品。</p>    <p> </p>    <p style="text-align: center;"> </p>    <p> </p>    <p>来自：https://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649691570&idx=1&sn=7677ba9f5a78ca22048ddaf097dec12f&chksm=88932ad1bfe4a3c71d84d824b7126addf81f1f9dbdc61f1fc954166ed9dec7deabcd3a08c747&scene=1&srcid=09094NwidAputoCWsq87wOA3&pass_ticket=QAyEOTyTA7mvXeaX15nIJNIkphHqMn1Adf1YVA4zBGE%3D#rd</p>    <p> </p>