转载

Docker为何未在生产环境中取得广泛成功？

Docker的发展势头一天比一天强劲，它显然在试图解决实际的问题。然而，对如今许多的生产环境用户来说，没有出现优点压倒缺点的局面。在开发、测试和持续性集成等环境下，Docker在让容器吸引广大开发人员方面确实有上佳的表现，不过它还没有颠覆生产环境。按照DockerCon 2015的“生产环境下的Docker”这一主题，我想公开讨论Docker想在生产环境使用场合下得到广泛采用还没有克服的种种挑战。这里提到的问题没有一个是新问题，它们都以某种形式出现在GitHub上。大多数问题我已经在大会演讲中或与Docker团队交流中讨论过。本文倒不是要明确指出什么不再是问题：比如说，新注册中心(registry)克服了旧注册中心的许多不足。本文并没有提到仍然问题重重的许多方面，不过我认为下面这些问题是近期内需要解决的最重的问题;只有解决了这些问题，更多的企业组织才能够迈出一大步，在生产环境中运行容器。我在电子商务公司Shopify运行Docker的经历对本文有很大的影响;一年多来，我们一直在容器上大规模运行核心平台。由于像Docker这样发展这么迅猛的技术，不可能一切都保持现状。如果你发现不正确之处，务必联系我。

映像构建

为大型应用程序构建容器映像依然是个挑战。如果我们要依赖容器映像用于测试、持续性集成和紧急部署，就需要在不到1分钟的时间内将映像准备就绪。Docker文件(Dockerfile)让这对大型应用程序来说几乎不可能。虽然Docker文件易于使用，但是位于过高的抽象层，无法支持复杂的使用场合：

带外缓存，面向特别错综复杂的、针对特定应用程序的依赖项;
在构建时访问密文(密码、密钥和相关内容)，又不将它们提交给映像
全面控制最终映像中的层
并行处理构建层

大多数人并不需要这些功能，但是对大型应用程序而言，其中许多功能是快速构建映像的先决条件。Chef和Puppet等配置管理软件使用广泛，但是让人觉得用于构建映像过于笨拙。我打赌，在今后十年内，现有形式的这类系统会因容器而逐渐退出历史舞台。然而，许多应用程序依赖它们来配置、部署和编排。Docker文件无法真实地记录下现在由配置管理系统管理的复杂性，但这种复杂性需要在某个地方加以管理。在Shopify，我们最后使用docker commit API，从头开始构建了自己的系统。这个过程很麻烦，我希望这一幕不会出现在任何人身上，我很想摆脱这种局面，但是我们又不得不扫除障碍。很少有人会花这么大的力气去管理用于生产环境的容器。

这个领域会出现什么情况不得而知;目前在这个领域，开展的研究工作并不多(一个例子是dockramp，这是另一种打包器)。Docker引擎会在将来有所改进，将构建基本步骤(添加文件和设置入口点等)与客户端(Docker文件)分开来。为版本1.8所做的合并工作已经让这变得更容易，为配置管理工具厂商、业余爱好者和公司进行试验尝试创造了条件。考虑到配置系统的历史还很短，认为一种标准有望搞定这个问题(就像运行时标准那样)是不切实际的。什么时候可以实现可扩展的映像构建，相当不明朗。据我所知，没人在积极迭代，很遗憾这种现状已维持一年多了。

垃圾收集

每个部署的重大Docker系统到头来要编写垃圾收集器，以便清除主机上的旧映像。使用了各种启发式方法，比如清除超过X天的旧映像，在主机上最多执行Y个映像。Spotify最近开放了其系统的源代码。我们还在很久以前就编写自己的垃圾收集器。我能明白为此设计一种易预测的用户界面(UI)有多难，但是这又是核心中绝对需要的。当生产环境的机器嚷着要存储空间时，大多数人无意中发现要求收集垃圾。最后，你会遇到同一映像，Docker注册中心因庞大映像而溢出，不过这个问题已列在了发行版路线图上(详见https://github.com/docker/distribution/blob/master/ROADMAP.md#deletes)。

迭代速度和核心状态

Docker引擎致力于1.x版本的稳定性。在版本1.5之前，降低准入门槛以便在生产环境得到采用方面所做的工作不多。开发容器的公众心理模式对Docker的成功而言必不可少，Docker害怕破坏这种模式是有其道理的。如果用户体验(UX)方面的每个变化经历的过程时间过长，迭代速度难免受到影响。自版本1.7起，Docker开始发布试验性版本，以网络和存储插件带头。这些功能特性被明确标为“未准备用于生产环境”，可能会从核心中取出或者随时经历重大变化。对于早已看好Docker的公司来说，下面这个是好消息：它让核心开发团队可以更快速地迭代开发新功能，不用担心本着最佳设计的精神而破坏次要版本之间的向后兼容性。公司仍然很难改动Docker核心，因为它需要分支――这是导致最终失败的行为和维护负担，或者需要得到上流接受;对于值得关注的补丁来说，这常常很耗费人力。自版本1.7起，宣布插件后，解决这个问题的策略就很明确：让每一个固执己见的的组件都可以插入，最后显示了“带电池而且可以更换”这种理念的成果，这种理念最早是在2014年的DockerCon欧洲大会上提出来的(不过相当模糊)。在6月份的DockerCon大会上，很高兴听到这归入到“管道”(Plumbing)这个大主题来探讨，作为核心开发团队的重中之重。虽然未来终于大有希望，但是这在今天仍然是个痛点，就跟过去两年一样。

日志

日志是表明有望得益于之前变化的一个方面的例子。这并不是引起强烈关注的问题，却是普遍性的问题。目前没有理想的、普通的解决方案。日志到处都是：尾部日志文件、容器里面的日志、通过挂载发送到主机的日志、发送到主机syslog的日志，通过fluentd(开源数据采集器)等工具来暴露日志，从应用程序直接发送到网络的日志，或者发送到文件的日志，让另一个进程将日志发送到Kafka。在版本1.6中，支持日志驱动程序的功能已并入到核心中(https://blog.docker.com/2015/04/docker-release-1-6/);然而，驱动程序在核心中必须得到接受(这并非易事)。在版本1.7中，已并入了试验性支持进程外插件的功能，但是让我失望的是，它并不随带日志驱动程序。我认为，版本1.8会计划添加这项功能，但是在官方记录中找不到这项。到那时，厂商们就能够编写自己的日志驱动程序。社区内部的共享将轻而易举，大型应用程序再也不必求助于设计定制的解决方案。

密文

迁移到容器的人大多数依赖配置管理，在机器上安全地配置密文;然而，继续沿着配置管理这种老路子配置容器中的密文很笨拙。另一个办法就是将密文与映像一同分发，但是这带来了安全风险，而且很难在开发、持续性集成和生产环境之间安全地回收映像。最纯粹的解决办法就是通过网络访问密文，让容器的文件系统保持无状态。就在不久前，这方面还没有任何面向容器的机制;不过最近，两家颇令人关注的密文代理系统Valut(https://vaultproject.io)和Keywhiz(https://github.com/square/keywhiz)开放了源代码。在Shopify，我们一年半前开发了ejson(ejson是一种简单的库，用嵌入在JSON文件中的公钥加密该文件中的所有值，详见https://www.shopify.com/technology/26892292-secrets-at-shopify-introducing-ejson)，以解决这个问题，从而管理JSON文件中非对称加密的密文文件;然而，它就所运行的环境有一些假设，因而让它与密文代理系统相比，不是很理想的一般性解决方案(如果你很好奇，可以参阅这篇文章https://www.shopify.com/technology/26892292-secrets-at-shopify-introducing-ejson)。

正文到此结束