转载

吐槽：Docker真的好吗？

英文原文： Lets review.. Docker (again)

本文是一篇对 Docker“吐槽”的文章，作者从 Dockerfile、缓存、分层文件系统、Docker Hub、安全、容器和虚拟机几个方面入手，阐述了 Docker 和容器技术目前存在的一些问题，以至于说 Docker 的存在并没有必要。大家可以把这篇文章的观点作为对 Docker 认识的一个补充，对 Docker 有一个更加客观的认识。

概述

距离我上次发表对 Docker 的看法已经一年了，那个时候我狠狠的批评了 Docker 在架构上的缺陷以及其糟糕的用户体验。虽然现在项目已经发展到 1.0，但是还是得到了一些来自亚马逊的不满，用户失望程度也在不断增加，面临大量的指责，甚至还存在一些可能会导致主机污染的漏洞。然而 Docker Hub 上个人私有仓库的引入，使得用户自己不需要再运行个人的 Registry，再加上 webhook 与 GitHub 整合，所有这些看起来是一个良好的开始。

于是我决定再给 Docker 一个“机会”，并且把其投入到生产中运行六个月，看看效果怎样。结果真的令我很失望，在使用过程中，Docker 表现很令人失望，不但性能糟糕，而且由于其本身功能的不足，我们还需要在解决方案上不断地进行变通，整个过程的用户体验也不尽如人意，这使得我几乎想要把自己的脸撞碎在桌子上！事实上，在我看来 Docker 的性能的确很糟糕，以至于缓存被禁用之后编译过程变得更快。（看看 reddit 和 hackernews 上面讨论）

Dockerfile

Dockerfile 有很多问题，在我看来，他很丑陋，有很多局限性，有的地方甚至相互矛盾，并且有很多根本性的缺陷。让我们来说说，假如你想创建单个仓库的多个镜像，例如第二个镜像包含了调试工具，但是对两个镜像的基本要是是一样的。Docker 不支持这样操作（per #9198 ），当前并没有能力去对 Dockerfile 进行扩展（per #735 ），使用子目录的话会破坏创建的上下文以及阻止你使用 ADD/COPY（per #2224 ），就像管道一样（per #2112 ），在容器构建的时候（build time）你也不能够使用环境变量根据不同的运行条件来改变指令（per #2637 ）。

我们的变通方案是创建一个基础的镜像，两个指定环境的镜像，以及一些包含重命名和 sed 替换的 Makefile 自动化脚本。还有一些意想不到不到的“ 特性 ”导致$HOME 环境变量消失了，还会产生一些没用的错误信息，使用起来的确很不方便。

Docker 缓存/分层

Docker 可以使用 COW（copy-on-write）文件系统来缓存 Dockerfile 指令，类似于 LVM 的快照，到现在仍然仅仅支持满是问题的 AuFS（AnotherUnionFS）。为了提高稳定性以及性能，之后在 0.7 版本中对 COW 做了不同的实现，你可以在这里了解到详细的情况。但是这个缓存系统并不智能，导致了一些令人惊讶的情况，比如不能阻止某一个指令被缓存(per #1996 )。并且很慢，鉴于这一点，如果你禁用缓存或者是避免使用分层，创建的速度反而快一点，在 Docker Hub 上传和下载的时候这个表现的更严重，详情会在下面部分进行描述：

这些问题都是由 Docker 的架构设计导致的，Docker 作为一个整体，总是线性的执行指令，即便是在很不合适的情况下也这样 (per #2439 )。作为一个改变慢速创建的变通方法，你可以使用一个第三方支持异步执行的工具，例如 Salt Slack ， Puppet ，甚至 Bash ，这样的话就完全放弃分层的思想使其毫无用武之地。

Docker Hub

Docker 鼓励通过 Docker Hub 来进行社交合作，允许你发布自己的 Dokerfiles，不管是公有的还是私有的，这样其他人可以基于此来通过 FROM 来进行扩展，而不是拷贝，粘贴。这个生态系统类似于 AWS marketplace 的 AMIs，以及 Vagrant 的 boxes ，原则上说是非常有用的。

然而由于一些原因，Docker Hub 在实现上是有缺陷的。Dockerfile 不支持多 FROM 指令(per #3378 , #5714 and #5726 )，这就意味着你只能继承自单个的镜像。并且他也没有强制版本化，例如 dockerfile/ubuntu:14.04 的作者可以替换掉这个标签的内容，这就相当于在使用了没有强制版本的包管理工具。另外在后面也会提到，Docker Hub 在速度上的缺陷也很令人失望。

Docker Hub 也有一个自动构建的系统，它可以监测仓库中新的提交，并且触发一个容器的创建。因为很多原因，这个功能基本上是没用处的。创建服务没有可定制化的功能，甚至连最基本的前/后脚本钩子也没有。它还强制使用一个指定的项目结构，希望在根目录中只有单一的 Dockerfile，导致创建过程变得相当的慢，也破坏了我们之前提到的创建的变通方法。

我们采用的变通方法是使用 CircleCI , 一个持续集成（CI）平台，可以触发基于 Makefile 的 Docker 创建，并推送到 Docker Hub。这个并不能解决速度慢的问题，唯一的解法就是使用我们自己的 Docker Registry，这样做确实有点复杂甚至可笑。

安全

Docker 原来使用 LXC 作为默认的执行环境，从 0.9 之后采用 libcontainer 作为默认的执行环境。当使用合适的执行驱动（exec-driver）时，引入它来调整命名空间的能力，权限以及使用定制的 LXC 配置。

Docker 需要一个根守护进程一直在主机上运行，并且有很多安全漏洞，比如 CVE-2014-6407 和 CVE-2014-6408 ，非常坦率的说，这还不应该排在第一位。即便是 Gartner，根据他们可怜的评估记录，也表达了对 Docker 不成熟，以及安全问题的担忧。

Docker，从设计上来说，对 namespace 能力过分的信任，但实际上 namespace 比一般的 hypervisor 暴露的攻击面要大很多，Xen 在 Linux 里面有 129 个 CVEs（Common Vulnerabilities and Exposures），与之相比它却有 1279 个。当然，这在某些情况下也是可以接受的，比如在 Travis CI 里面以公有的方式来构建，但是在私有情况下和多用户的环境下，就显得比较危险了。

容器不是虚拟机

namespaces 和 cgroups 是非常强大的，允许一个进程及其子进程有一个共享内核资源的私有视图，例如网络栈和进程表。这种粒度的控制和隔离，加上 chroot jailing 和 grsec ，可以提供一个很优秀的保护层。有些应用，例如 uWSGI ，直接对这些优点加以利用，而不是通过 Docker。还有些应用不直接支持 namespaces 的可以用 firejail 封装成沙箱。如果你觉得很冒险的话，你也可以直接在你的代码里面支持 namespace。

容器化项目，诸如 LXC 和 Docker，利用这些特性，可以高效的在一个相同的内核空间中运行多个 linux 的发行版。与 hypervisor 相比，它们有时候会有一些优点，比如占用更少的内存并且启动速度更快。但是这是以损失完全性，稳定性和兼容性为代价的。这里有一个跟 Linux 内核接口有关的边缘情况，在内核和用户空间运行非兼容的和没有经过测试的 glibc 版本组合会导致一些不可预料的行为。

回到 2008 年，当 LXC 被设想出来的时候，硬件辅助的虚拟化才有几年的时间，很多 hypervisor 有性能和稳定性的问题，这样的虚拟化并没有被广泛的使用，也只是为了降低花费和减少物理机而做了折衷。但是现在 hypervisor 的性能已经可以和物理机器一样快了，有趣的是，在一些情况下可能更快。运行自定义的虚拟机也变的更快更便宜，随着 DigitalOcean 在性能和花费方面不断的超越 EC2，使得以一对一的方式运行应用和虚拟机，在财政上变的成为可能。

Bryan Cantrill 在这里指出，虚拟化的性能主要取决于工作负载的类型，比如 IO 很重的应用会导致更低的性能。

对于有些特定的情况，使用容器化是正确的选择，但是除非你能很明确的解释为什么你要使用容器，否则你便可以使用 hypervisor 来代替。即便是你使用了传统的虚拟化，你也可以直接应用 namespaces 的优势，诸如 firejail 就可以帮助你的应该在缺少本地支持的情况下来实现这样的特性。