转载

生产环境下的Docker：成功、挫败和教训

Docker在2014年迎来了迅猛的发展，不过在年底传出了围绕Docker的一些声音，声称容器服务基础设施已达到了准备用于生产环境的程度。今年，Gartner等调研公司已经列出了Docker部署到企业中分布式应用程序中的安全挑战，不过都相当支持Docker总体的发展方向。新年伊始，已经出现了好几个例子，它们证明了使用容器以便持续改进和日常部署在生产环境中的准备就绪状况。

用户们的体验不一而足：有的用户坚信可以使用Docker大规模部署分布式Web应用程序;有的用户已把Docker整合到生产环境中;有的用户决定还没有这么做，而有的用户则拒绝Docker，认为它太过复杂或不够稳定，无法用于实际的使用场合。

下面不妨看一下今年的四个例子，它们证明了用户如何考虑Docker用于生产环境：

Battlefy：交付新的功能特性

软件工程师Jaime Bueza最近撰写的一篇博文表明了初创公司Battlefy如何使用Docker和Jenkins工具，在其eSports平台上发布新的功能特性时，迅速构建并发布Docker映像，然后将映像部署到AWS Elastic Beanstalk上，或者修复软件错误。在过去的五个月，Battlefy的访客数量已从100个猛增到400000个，它所在的行业预计全球收入有望增长24%;国际用户群数量已经超过了7000万。

Battlefy从功能特性或软件错误的GitHub合并请求(pull request)入手，连接到JIRA工单，然后利用测试版工具Screener来检测每个版本的DOM变化，并将差异做入屏幕截图。结果被发送到团队的Slack频道，评审团队成员给代码打上两个大拇指表情符号后，Jenkins就向AWS S3交付新的代码;Docker容器被用来构建生产前环境。在生产前环境中完成另一轮的Screener前端测试后，Jenkins随后得以自动将合并请求并入到主生产环境中。

Battlefy生怕遇到生产环境中的任何故障，于是使用AWS Elastic Beanstalk，那样如果构建、推送和部署的Docker映像有错误，Battlefy就能迅速恢复到前一个版本。

Iron.io：在微服务环境中运用Docker

Iron.io是IronMQ消息队列系统和IronWorker异步任务处理工具的开发商，它自豪地自认为是Docker的早期采用者;对它来说，微服务架构已俨然成为运行时环境的标准化模式。

在近日的一篇博文中，渠道和整合主管Ivan Dwyer解释，对Iron.io来说，它们之所以能避免生产环境在安全、发现和故障方面的重大挑战，就是因为它们在容器层面把Docker整合到系统中：

“我们把每一个任务容器视作一种暂时的计算资源。持续性、冗余性和可用性，我们在服务层面扩建产品时非常注重这一切要素，未必适用于单个的任务容器层面。我们在这方面关注的问题实际上局限于确保本该运行时运行，好让我们确信如今在充分利用Docker。”

IronWorker在块存储系统中拥有超过15套的Docker映像，它们为运行中的代码提供了语言和库环境。IronWorker的客户随后只能利用编写代码所需的库，并上传到Iron.io的S3文件存储环境，他们的消息队列将底层的Docker映像与用户的代码程序包在新的容器里面合并起来，运行进程，然后销毁容器。

Iron.io在微服务环境下工作，许多遗留的企业生产环境无法使用这种环境，因为它们的可组合性根本不如Iron.io支持的环境。但是就较新的应用开发环境而言，Iron.io可以在生产环境中使用Docker，帮助最终用户管理成本，并且根据需要在编排基础设施里面扩展进程。

Mikamai：开发公司期望Docker与Opsworks一并部署

来自开发商Mikamai的开发人员Giovanni Intini总结了许多成熟的开发人员在Docker方面的几个常见问题：乍一看，大家都喜欢这个概念;他们也喜欢其潜力。不过他们也都有过前车之鉴，不敢过于仓促地采用新技术，因为那样会导致他们在部署到生产环境后不得不通宵达旦地工作或者放弃为期三天的周末。对二十出头的编程新手来说，这可能很好玩;但是对于三四十岁的人来说，工作不是生活的全部，在生产就绪的环境中采用新技术面临的风险是更重大的决定性因素。

Intini仍然看好Docker的潜力;由于基于云的开发运维(DevOps)生态系统还没有足够成熟起来，他构建了一些新的开源项目，以便使用亚马逊的Opsworks(目前还无法支持Docker)等既有服务，能够将Docker化的容器服务部署到生产环境中。

Intini的应用架构需要负载均衡系统、前端Web服务器、避免任何故障时间的haproxy、应用容器、Redis、PostgreSQL、计划任务(cron)和异步处理。他想把将其应用程序构建成具有可扩展性的docker化的应用程序。问题在于，当他开发的应用程序在亚马逊网络服务云上运行时，Docker其实并不是一种选择。Intini在近日的博文中分享了用来构建扩展其应用程序的生产就绪的环境的代码和进程，现在他声称其应用程序在部署环境中的停运时间为零。

XMLDirector：反对使用Docker

Andreas Jung是XMLDirector的项目负责人，而XMLDirector是一个XML内容管理系统和工作流平台，旨在支持企业XML环境，其工具可以转换发布格式以及管理文档集合。

两周前，他撰文描述了如何试图在生产环境中使用Docker，将特定的XML类型数据库放入到容器中，以便它们可以迅速地安装和管理;将Plone企业内容管理系统应用程序放入到容器中，以便它可以用于XML Director的演示;以及将众多XML特有的数据库放入到容器中，以便它们可用于对照处理其他XML数据库后端的方法，测试XML Director的后端。

可惜Docker没有给Jung留下深刻的印象。他发现，通常的构建过程比使用外壳还要慢5倍至10倍;几个进程需要重启Docker;由于Docker创建多个映像和容器，测试后删除系统上的副本需要一番“捣鼓”。

试图使用Docker无果后，Jung只好回到“老式的部署环境”，尽管他也承认Docker背后的理论和概念确实不错(不过他表示“Docker的架构和实施一团糟。Docker在生产环境中完全不稳定。它不可靠，无法预测，靠不住。”)

准备好用于生产环境吗?视情况而定

Docker已得到了巨大的发展，生态系统在不断扩大，而且容器化系统在金融机构、媒体及其他大规模跨国企业领域当中得到了采用。虽然Docker的容器技术迅速被认为是构建投入到生产环境的分布式应用程序的标准，但早期采用者发觉它最适合这种使用场合：企业已经深思熟虑了如何为其应用程序构建微服务架构。

正文到此结束