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

译文
云计算
如今Docker需要的是更多的人将容器部署到生产环境,而且是大批人在部署。遗憾的是,许多公司一开始就对PaaS寄以厚望,利用当前的架构过度补偿。如果你规模很小,或者规划将Docker部署到全新的环境,这种方法才可行。想在生产环境下得到更广泛的使用,我们就需要解决本提到的一些问题,以便让Docker的优点明显压倒缺点。

[[143394]]

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)。

#p#

文件系统

Docker依赖来自文件系统的写时拷贝机制(CoW)。这是为了确保如果有100个容器是从一个映像运行的,你就不需要100倍的磁盘空间。相反,每个容器在映像上面创建一个CoW层,只有利用原始映像创建文件时,才使用磁盘空间。容器的“规范市民”对容器里面的文件系统带来的影响极小,因为这类变化意味着容器具有了状态,这是绝对禁止的。这类状态应该存储在映射到主机或的卷上或通过网络来存储。此外,层次技术节省了部署之间的存储空间,因为映像常常相似,有共同的层。在Linux上支持CoW的文件系统存在的问题是,它们都有点新。我们Shopify在几百个负载相当大的主机上遇到过几种文件系统:

AUFS。看到整个分区在我们要重新挂载的地方锁起来。速度缓慢,耗用大量内存。代码库很庞大,难以读取,这可能就是为什么它没有被接受、进入到上游,因而需要自定义内核。

BTRFS。面临学习曲线,需要学用一套新的工具,因为du和ls不管用。与AUFS一样,我们看到分区冻结,内核锁隹,尽管玩猫捉老鼠的游戏,希望内核版本保持是最新版本。临近磁盘空间极限时,BTRFS的行为捉摸不定,如果你有1000个这样的CoW层(用BTRFS的术语来说是子卷),也是如此。BTRFS耗用大量内存。

OverlayFS。这在3.18版本中已并入到Linux内核,对我们来说已相当稳定、快速。它耗用的内存要少得多,因为它设法在索引节点(inode)之间共享页面缓存。遗憾的是,它需要你运行未被大多数发行版采用的较新内核,这常常意味着构建自己的内核。

幸好对Docker来说,Overlay文件系统很快就会无所不在,不过在我们看来,运行大量节点时,AUFS这一默认文件系统对生产环境来说仍然很不安全。不过很难说在这里该如何是好,因为大多数发行版也并不随带已准备支持Overlay的内核(有人提议Overlay作为默认文件系统,但由于这个原因遭到驳斥),不过这绝对是这个领域的发展方向。看来我们除了等待别无他法。

依赖处于前沿的内核功能

正如Docker依赖最前沿的文件系统那样,它还充分利用最近为内核添加的大量功能特性,也就是命名空间以及不是太新,又不常使用的控制组(cgroup)。这些特性(尤其是命名空间)还没有在业界得到广泛采用,因而还没有经过考验。我们偶尔会遇到这些特性存在的不明显错误。我们碰到网络命名空间在生产环境下被禁用的情况,那是由于我们遇到过相当多的软死锁,事后查明这些软死锁与实施有关,却又没有资源从上流解决问题。内存控制组耗用相当多的内存,我听到过外头反映不可靠的情况。随着容器得到越来越广泛的使用,大公司可能会率先做好这项稳定工作。

我们在生产环境中碰到的需要加固的一个例子就是僵尸进程(https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/)。容器在PID命名空间里面运行,这就意味着容器里面的第一个进程有pid 1。容器里面的init需要执行确认已死的子进程这一特殊任务。某个进程死后,并不立即从内核进程数据结构中消失,而是成为一个僵尸进程。这确保了父进程可以通过wait(2)检测到子进程已死。然而,如果子进程成为孤儿,其父进程就被设成init。该进程随后死后,init的任务就是通过wait(2)确认子进程已死――不然,僵尸进程就会永远存在。这样一来,内核进程数据结构会被僵尸进程耗尽,之后你就得自己想办法。对基于进程的master/worker模式来说,这种场景相当常见。如果worker进程逃出外壳,并花了很长时间,master进程就会使用SIGKILL终结等待外壳命令的worker进程(除非你使用进程组,一下子终结整个进程组)。逃出外壳的派生进程然后被init继承。等该进程终于完成后,init需要对它执行wait(2)操作。Docker引擎可以解决这个问题,通过Docker引擎使用设置PR_SET_CHILD_SUBREAPER确认容器里面的僵尸进程,https://github.com/docker/docker/issues/11529有所描述。

安全

运行时安全对容器来说仍要打个问号;想针对生产环境进行加固是经典的先有鸡还是先有蛋的安全问题。以我们Shopify为例,我们并不依赖容器提供任何额外的安全保障。然而,许多使用场合却依赖容器提供额外保障。由于这个原因,大多数厂商仍在虚拟机中运行容器,而虚拟机的安全久经考验。由于操作系统虚拟机胜出,我希望看到虚拟机在今后十年内消失,因为有人曾在Linux邮件列表上说过:“我曾经听到虚拟机管理程序是活生生的证据,证明了操作系统的无能。”容器在虚拟机(硬件层虚拟化)和PaaS之间(应用程序层)提供了完美的中间体。我知道,运行时安全方面在做更多的工作,比如说能够将系统调用列入黑名单。映像方面的安全一向是问题的根源,但是Docker正在借助libtrust和notary――它们将是新的发行层(https://github.com/docker/distribution)的一部分的,积极改进这方面。

映像层和传输

  • 第一个版本的Docker为映像的构建、传输和运行时环境采取了一条巧妙的捷径。它选择了适用于所有情况的工具:文件系统层,而不是为每个问题选择一种合适的工具。这种抽象机制一直作用于在生产环境中运行容器。这是完全可以接受的最小可行产品实用主义,但是每个问题都能极其高效地得到解决。
  • 映像构建可以表示为有向工作图。这样可以弄清楚缓存和并行处理,以便迅速地构建可预测的映像。
  • 映像传输而不是使用映像层,它就可以执行二进制差异化(binary diffing)。这个话题已研究了几十年。分发层和运行层越来越分离开来,为这种优化创造了条件。
  • 运行时环境应该就实施单单一个CoW层,而不是再次使用随意的映像层抽象。如果你在第一次读取时使用AUFS之类的统一文件系统,就遍历链接文件列表来汇编最终文件。这很缓慢,而且完全没有必要。

层模式对映像传输以及对构建来说是个问题。这意味着,你必须极其小心对待映像每个层中的东西,因为不然你很可能到头来为大型应用程序传输100MB的数据。如果你在自己的数据中心里面有大型链接,这个问题不大,但是如果你想使用Docker Hub之类的注册中心服务,这就会通过公开的互联网来传输。映像分发目前正在积极开发之中。Docker公司有足够的动机将这方面做得可靠、安全而快速。至于构建,我希望这为插件创造条件,以便一种优秀的解决方案浮出水面。

结束语

另外许多话题有意没有探讨,比如存储、网络、多租户、编排和服务发现。如今Docker需要的是更多的人将容器部署到生产环境,而且是大批人在部署。遗憾的是,许多公司一开始就对PaaS寄以厚望,利用当前的架构过度补偿。如果你规模很小,或者规划将Docker部署到全新的环境,这种方法才可行。想在生产环境下得到更广泛的使用,我们就需要解决上述一些问题,以便让Docker的优点明显压倒缺点。

Docker将自己置于令人兴奋的位置,充当PaaS的接口,无论是发现、网络还是服务发现,应用程序没必要关心底层基础设施。这是好消息,因为正如Solomon所说,Docker的最大优点就是,它让人们达成了共识。我们终于开始就映像和运行时环境之外的其他方面达成共识。

我与Docker公司的人员深入探讨过所有上述问题。在一定程度上存在所有这些问题的GitHub Issues。我在这里的目的是,仅仅是提供个人之见,阐明哪几个方面对降低Docker的准入门槛最为重要。我对未来满怀激情,但是我们仍有大量工作要做,才能让Docker应用到更多的生产环境。

原文标题:Why Docker is Not Yet Succeeding Widely in Production
 

 

责任编辑:Ophira 来源: 51CTO
相关推荐

2022-09-04 21:17:03

高可用Linkerd

2011-09-19 10:43:19

Nuget

2020-02-25 15:47:05

ElasticsearLucene地方

2022-05-26 09:00:00

网站抓取Lightrun开发

2021-12-03 07:27:29

EFCore生产环境

2015-02-27 09:00:54

Docker微服务容器技术

2020-12-25 09:00:00

Kubernetes容器开发

2015-10-28 16:20:10

短生命周期容器原生云计算

2020-09-14 07:00:00

云计算多云环境多云策略

2013-07-11 09:20:57

Android开放

2019-09-18 20:46:57

容器生产环境数据中心

2023-11-14 17:40:32

2018-11-20 10:10:54

Redis数据库模糊查询

2012-02-07 09:56:06

无代理防毒产品

2016-01-08 09:49:19

DockerDocker案例云应用开发

2013-09-30 09:40:37

VDI部署VDI

2020-09-14 15:30:23

开发技能代码

2020-11-23 07:56:08

Vue生产环境

2015-11-20 15:28:36

AWSGoAWS SDK for

2018-07-12 16:02:01

SQLMySQLMongoDB
点赞
收藏

51CTO技术栈公众号