为何Docker还未在产品中取得广泛成功

jopen 7年前
 

[编者的话] 作为工作与第一线的Docker使用者,本文作者向大家描述了当前Docker无法满足产品用例的几个方面,以及未来的发展动向,供广大Docker使用者参考。

注:由于原文作者文笔十分“神奇”,译文无法保证准确表达作者的本意,请参考原文理解。

截至上周,Docker一直处于上升势头,这其中也涉及到一些实质性问题。对于当今许多产品的用户而言,使用Docker却是弊大于利的。Docker漂亮地使得容器技术对于开发者充满吸引,尤其是在开发、测试以及CI环境下,但是它也确实破坏了生产。在DockerCon 2015的 “Docker in Production”一主题 中,我想开诚布公地谈谈Docker面临的挑战,以使它能适合产品的用例。这里提到的都不是新问题;它们均在GitHub中以某种形式存在着。其中绝大多数问题,我都已经在 会议提及 ,或已和Docker团队讨论过。本文不会明确指出哪些问题已经不复存在:例如,新的注册机制改进了旧版本的很多缺板。虽然许多看似存在问题的地方不会在文中提及,但是我个人坚信接下来提到的问题是至关重要的,需要在短时间内修复,以使得更多的组织能够在产品中使用容器。在Shopify,我们大规模地使核心平台运行于容器之上,现已超过一年时间,因此这里的列表无疑更倾向于 本人使用Docker的经验 。对于像Docker这样发展如此迅速的技术,保证一切通用基本是不可能的。因此,当你发现错误时,还望能够 伸出援手

镜像搭建

为大型应用搭建容器镜像依旧是一项挑战。如果我们依靠容器镜像来进行测试、CI和应急部署,那么我们便须在1分钟内准备好这个镜像。 Dockerfile的存在使其这对于大型应用而言基本是不可能的完成的事。纵使它易于使用,但是它的抽象层次太高,以至于不能应对复杂的用例:

  • 为重量级的面向应用的依赖提供带外缓存
  • 在构建期间的访问密钥,避免提交到镜像
  • 对于最终镜像层级的完全控制
  • 层级构建的并行化

绝大多数人不需要这些特性,但是对于大型应用而言,它们却是快速构建的前提条件。诸如Chef和Puppet之类的广泛应用的配置管理软件,对于镜像构建而言依旧过于笨拙。我敢打赌,未来5年内当前这种形式的系统将不复存在,并为容器取代。然而,许多应用依靠它们实现供应、部署和业务流。 Dockerfile并不能实实在在地应对当前由配置管理所管控的复杂度,但在某些地方这种复杂度确实需要被控制。在Shopify,我们最终通过 docker的commit API 重新实现了我们的系统 。这是痛苦的,我希望大家不会经历这个“痛苦”并渴望摒弃它,但目前我们真的只能自己来排除困难。只是很少有人会如此大篇幅地来讨论面向产品的容器。

很难说这个领域将出现什么,并且当前在这个领域也并未进行多少探索(其中一个例子是 dockramp ,另一个是 packer )。未来Docker引擎将继续 改进 ,以拆分客户端(Dockerfile)的构建原语(如添加文件、设置入口等)。 合并到1.8版本的工作 将会使得上述工作变得更加简单,它将向配置管理供应商、爱好者及公司开放一块试验田。考虑到供应系统的历史,认为一个标准会解决这些问题是不切实际的, 正如运行时那样 。同样,关于可伸缩镜像构建这一特性当前也是相当不明确的。据我所知,并没有人在积极地倡导,更糟糕的是,它已经有一年以上没变化了。

垃圾回收

每个Docker的主要部署人员最终都会写一个垃圾回收器(以下简称GC),来 移除主机中的旧镜像 。这用到了各种方法,例如移除x天之前的镜像,并确保至多只有y个镜像存在主机中。Spotify最近 将它们开源 了。很早之前,我们也一样实现了我们自己的GC。我能够理解为GC实现一个可预见的UI有多难,但这确实是最需要的东西。大多数人发现他们只是在其产品容器的空间不足时,才偶尔需要GC。最后,你也将会遇到这个问题:传到Docker registry的相同镜像溢出为大镜像[译者:复数],好在,这个问题已经在 分布式规划 中提出。

迭代速度以及内核状态

在1.x的发行版中Docker引擎关注的是稳定性。Pre-1.5则是投入了少量工作来降低产品接入使用的门槛。开放容器生态模型是Docker成功所必须的,并且他们害怕破坏这个模型。当前,Docker迭代速度总是得忍受如下问题:每次UX变更都要经历过多流程。Docker 1.7则是发布了网络和存储插件牵头的 实验性版本 。这些特性被明确标注为“不适用于产品”并且随时可能会被移除或修改。对于那些已经押注Docker的公司而言,这是一则好消息,因为这将使得核心团队对于新特性完成更快速的迭代,且无需关心“最佳实践”中的向后兼容性。对于公司而言,修改Docker内核依旧很困难,因为这需要fork或是取得上游的采用,前者风险高,维护负担重,后者对于那些有趣的补丁而言则显得耗时费力。随着1.7版插件模式的公布,处理这类问题的策略变得明晰:使每个可选组件都是可插拔的。这种“水果拼盘”式的哲学于 DockerCon Europe 2014 首次引入,尽管还很模糊。在6月的DockerCon,很高兴地得知这个策略由作为第一纵列的 Plumbing团队全权文档化 (这对我是最重要的,因为海象是我最喜爱的海洋哺乳动物,而Plumbing正是以它作为 吉祥物 )[译者:呵呵]。正如过去2年一样,它现在依旧是一个痛处,即使未来终于看起来有点盼头了。

日志记录

日志是本可以早点改进而获利的领域之一。它很难成为一个有吸引力的问题,但是它绝对是一个普遍性的问题。当前并没有优秀且通用的解决方案。这里充斥着各种方案:tail日志文件,记录到容器内,记录到挂载的主机,记录到主机的syslog,通过某些东西暴露日志(如 fluentd ),通过应用记录到网络,或者是记录到一个文件并由另一个进程将日志发送到Kafka。 Docker1.6支持合并到内核中的日志驱动 ;然而,驱动被内核采纳是 很不容易 的。1.7版本中, 进程外插件被实验性支持 ,但是,令人失望的是,它并未附带日志驱动。我认为这将是1.8版本的计划,但并未找到任何官方记录。就这点来看,供应商未来将能够编写它们自己的日志驱动。或许,社区内分享将会变得微不足道,而且大型应用将不再需要定制解决方案。

密钥

在“频繁而遍存”这一类目中,我们同样找到了密钥。大多数人在迁移容器时,依赖配置管理来 安全地提供机器上的密钥 ;然而,因为密钥而一直采用同样的在配置管理路径并不太理想。一个可选方案是通过镜像来散布它们,但这具有安全隐患,并且会使得在开发、持续集成以及生产之间循环镜像变得困难。最纯粹的方案是通过网络获取密钥,保持镜像的文件系统无状态。直到最近,这个领域还不存在什么面向容器的解决方案,但是即将有2款引人注目的密钥代理开源,分别是 VaultKeywhiz 。在Shopify,我们于一年半前 开发了ejson 来解决这个问题,它被用来管理JSON格式的非对称加密密钥文件;然而,它会对其运行环境做一定的假设,因此和密钥代理相比,显得不是那么通用(如果你感兴趣,可以阅读 这篇文章 )。

文件系统

Docker依赖于文件系统的写时复制 CoW (LWN上关于联合文件系统Union FS的 系列文章 ,它们使CoW成为可能)。这项特性确保当你拥有100个容器时,不需要对应的100倍磁盘空间。每个容器都只是在镜像的顶部创建CoW层,它们只在改变原始镜像的文件时才使用必要的磁盘空间。好的容器使用者会尽可能避免对容器内部的文件系统产生影响,因为这意味着使容器保持某种状态,是为大忌。这种状态应该被存储在映射到主机的卷或者网络上。此外,层级存储能够在部署时节省空间,因为镜像通常是相似的,它们拥有一些共同的层。在Linux上支持CoW的问题在于它们太“新”了。在Shopify有几百台主机在重负荷下运行,这里有一些经验:

  • AUFS 曾发现在需要重新挂载时,整个分区被锁住的情况。迟钝且占用大量内存。代码基巨大,难以阅读,似乎这正是它不被上游接受的原因,因此需要一个定制的内核。
  • BTRFS 因为du和ls不能工作,新的工具集有一定的学习曲线。和AUFS一样,我们同样发现了分区冻结和内核锁死,不管我们如何更新内核版本。当接近磁盘空间上限时,BTRFS的行为变得不可预测,并且当我们拥有1000份CoW层(BTRFS中的子卷)时,BTRFS同样会占用大量内存。
  • OverlayFS 这在Linux3.18内核中并入,对于我们而言,它现在已经 相当稳定和快速 了。由于采用在inode间共享页缓存,它 占用的内存少了很多 。不幸的是,它需要你运行最新的内核,而这些内核往往未被大多数发行版采用,因此通常需要我们自己来编译一个。

所幸的是,对于Docker而言,Overlay很快就会普及了,而默认的AUFS对于产品而言依旧不太安全,根据我们的经验,这种情况在运行大量节点时尤甚。很难说这里需要做些什么,因为大多数发行版并未配备兼容Overlay的内核( Overlay被提议为默认FS ,但是由于这里的原因最终被拒了)。虽然Overlay正是此领域的发展方向,不过我们还需等一阵子。

依赖于内核边缘特性

正如Docker依赖前沿的文件系统那样,它同样依赖大量内核的新特性,也就是namespace和cgroup(不是新的但却是最常用的)。这些特性(尤其是命名空间)还不够成熟以在生产中广泛应用。我们 偶尔 会遇到由于它们所造成的模糊的bug。在产品中,我们并未开启网络命名空间,因为我们曾经历过一些软锁死的情况,并追踪到它的实现,但没能修复其上游。内存cgroup会使用 相当数量的内存 ,并且我们也收到过外界谓之不可靠的报告。随着容器被越来越频繁地使用,相信大公司应该会率先解决稳定性问题的。

我们曾遇到过的一个 顽固的例子 就是僵尸进程。一个容器运行在PID命名空间,意味着这个容器内的第一个进程的pid就是1。容器内的init需要有 获知子进程结束 的特殊能力。当一个进程结束时,它并不会马上从内核的进程数据结构中消失,而是成为一个僵尸进程。这保证了其父进程可以通过wait(2)来检测其是否终止。然而,如果一个进程没有父进程,那么它的父进程将被设置为init。当这个进程结束时,通过wait(2)获知子进程的终止就成了init的工作,否则这个僵尸进程就永远不会结束。通过这种方式,你便可以通过僵尸进程耗尽内核的进程数据结构。在基于进程的master/worker模型中,这种场景是十分普遍的。如果一个worker需要调用命令[原文:shell out],这会占用很长世间,master可能会通过SIGKILL终止worker对shell命令的等待(除非你使用 进程组并一次性kill整个组 ,但基本不这么做)。由于命令调用而Fork出来的进程之后会被init继承。当它最终结束时,init需要对其使用wait(2)。Docker引擎可以通过PR_SET_CHILD_SUBREAPER来承认部分容器内的僵尸进程,这在 #11529 中有描述。

安全

对于容器而言,运行时的安全在某种情况下依旧是一个问题,并且要让其对于产品足够“坚固”是一个经典“鸡与蛋”的安全问题。在我们的例子中,我们并不依靠容器提供任何额外的安全保证。不过,有些用例却这么做了。出于这个原因, 大多数供应商依旧在虚拟机上运行容器 ,这种安全是经过考验过的。我希望在未来10年内看到虚拟机绝迹,因为操作系统虚拟化赢得了这场“战争”,正如 某人曾经在Linux邮件列表中所说 :“我曾听到过一种言论:管理程序的存在是操作系统无能的证据”。容器提供了介于虚拟机(硬件级虚拟化)和PaaS(应用层次)之间的 完美的中庸之道 。我知道更多对于运行时的改进已经完成,比如系统调用黑名单。围绕镜像的安全也已经 引起关注 ,但是Docker正在通过 libtrustnotary 改进这个问题,后者是 新的分布层 的一部分。

镜像层和传输

在Docker的第一次迭代中,它对于镜像构建、传输和运行时就走了一条捷径。它并不是针对每个问题选取正确的工具,而是选择了一个能够解决所有情况的工具:文件系统层。这种抽象一直暴露到在产品中运行容器。[译者:This abstraction leaks all the way down to running the container in production.大家自己理解下吧。。。]这是一种完全可以接受的最小成本的产品使用主义,但是其中的每个问题本都可以被更加有效地解决:

  • 镜像创建 这项工作可以用有向图表示。它允许识别出可以缓存和并行化的部分,以完成快速的可预测的构建。
  • 镜像传输 它完全可以使用 二进制diff ,而不是使用镜像层。这是一个已经研究了几十年的课题。分布层和运行时层变得越来越分离,开放了这方面的优化空间。
  • 运行时 应该只是做一个单独的CoW层,而不是再次使用任意的镜像层抽象。如果你正在使用一个联合文件系统,比如AUFS,在第一次读取时,你需要便利一个文件链表来组装成最终的文件,缓慢且完全不必要的。

这个层次模型对于传输而言是一个问题(正如之前所述,对构建也一样)。这意味着,您需要格外关心镜像中的每一层有些什么东西,否则你可能轻易地需要为一个巨大的应用传输100多兆数据。如果在你的数据中心中有大量链接,这并不是什么大问题,但是我如果你希望使用诸如Docker Hub之类的注册服务,这可是在开放网络上传输的。 镜像分布在继续工作着 。这里有很多理由促使Docker公司让其变得坚固、安全和迅速。正如构建一样,我希望它能够对插件开放,以形成一个好的解决方案。与构建器相反,如果有诸如bittorrent分布的特殊机制,人们应该能够普遍认可。

总结

这里有意避免提及许多话题,诸如存储、网络、多租户、业务流以及服务发现。Docker现在更需要的是让更多人在生产环境中大规模使用容器。不幸的是,许多公司从一开始就 朝着在PaaS的光辉 下过分补偿它们的技术栈。这种方式只适用于小规模产品,且计划使用Docker进行绿场部署[译者:从无到有],这种情况下基本不会遭遇产品的模糊性[译者: 联系灰场部署理解]。为了见到Docker在产品中更广泛的应用,我们需要解决上面强调的问题,来支持Docker。

Docker置身于一个有趣的位置,它作为PaaS的接口进行探索,使得应用的网络发现和服务发现不需要关心下层设施。这是一则好消息,因为正如Solomon所说,关于Docker最好的部分便是它让人们就某些事达成共识。我们终于开始赞同除了镜像和运行时之外的东西。

上述的话题,我都已经和Docker公司的好些人讨论过了,并且GitHub Issue也有很多留给他们。这里我所尝试做的只是,为最重要的领域提供一个可选的视角,来降低准入门槛。对于未来,我很兴奋,但是我们依旧要做很多工作来使在产品中运行Docker更加可行。