生产中的Docker：成功、挫折和经验教训。今年，Gartner等研究公司列出了在企业中将Docker部署到分布式应用程序所面临的安全挑战，但它们都支持Docker的整体发展方向。随着新的一年的开始，已经有几个例子证明了使用容器进行持续改进和生产日常部署的准备情况。用户的体验喜忧参半：一些用户坚信他们可以使用Docker来大规模部署分布式Web应用程序；部分用户已经将Docker集成到生产环境中；有些用户决定暂时不这样做，有些用户则拒绝Docker，认为它太复杂或不够稳定，无法实际使用。以下是用户如何考虑将Docker用于生产环境的四个示例：Battlefy：交付新功能发布Docker镜像，然后将镜像部署到AWSElasticBeanstalk，或修复软件错误。在过去五个月里，Battlefy的访客人数从100人猛增至400,000人，该行业的全球收入预计将增长24%；其国际用户群已超过7000万。Battlefy从针对某个功能或软件错误的GitHub合并请求（pullrequest）开始，连接到JIRA票证，然后使用beta工具Screener检测每个版本的DOM更改并将差异制作成屏幕截图。结果被发送到团队的Slack频道，在审查团队成员给代码两个竖起大拇指的表情符号后，Jenkins将新代码交付到AWSS3；Docker容器用于构建预生产环境。在预生产环境中经过另一轮Screener前端测试后，Jenkins便能够自动将合并请求合并到主生产环境中。由于担心生产环境出现任何故障，Battlefy使用了AWSElasticBeanstalk，这样如果构建、推送和部署的Docker镜像出现错误，Battlefy可以快速恢复到之前的版本。Iron.io：在微服务环境中使用Docker成为运行时环境的标准化模式。在最近的一篇博文中，渠道和集成总监IvanDwyer解释说，对于Iron.io，他们能够避免在安全、发现和故障方面的重大生产挑战，因为他们在容器级别集成了Docker。对系统：“我们把每一个任务容器看作是一个临时的计算资源。连续性、冗余和可用性，我们在服务层面扩展产品时非常关注所有这些要素，这可能不适用于单个任务容器层面。”我们在这里的重点实际上仅限于确保事情在它们应该运行的时候运行，这样我们就可以确信我们今天正在充分利用Docker。”IronWorker在块存储系统上有超过15个运行代码的Docker镜像提供了语言和库环境，IronWorker客户可以只需要编写代码所需的库并上传到Iron.io的S3文件存储环境，以及他们的消息队列将底层Docker镜像与用户的代码包合并到一个新的容器中，运行进程，然后销毁容器。Iron.io在微服务环境中工作，许多遗留企业生产环境无法使用，因为它们不像Iron.io支持的环境。但对于较新的应用程序开发环境，Iron.io可以在生产中使用Docker，帮助最终用户根据需要在编排基础架构内管理成本和扩展流程。Mikamai：开发公司期望Docker与Opsworks潜力一起部署.但他们都过于仓促地采用了一项新技术，这会迫使他们全职工作l在部署到生产后，晚上或放弃三天的周末。对于二十出头的编程新手来说，这可能很有趣；但对于三四十岁的人来说，工作并不是生活的全部，在生产就绪环境中采用新技术所涉及的风险是一个更大的决定因素。Intini仍然看好Docker的潜力；由于基于云的DevOps生态系统还不够成熟，他正在构建一些新的开源项目，以使用现有服务，如亚马逊的Opsworks（尚不支持Docker），将Dockerized容器服务部署到生产环境。Intini的应用程序架构需要负载平衡系统、前端Web服务器、避免任何停机的haproxy、应用程序容器、Redis、PostgreSQL、计划任务(cron)和异步处理。他想将他的应用程序构建成可扩展的dockerized应用程序。问题是，当他开发的应用程序在AmazonWebServices云上运行时，Docker并不是一个真正的选择。在最近的一篇博客文章中，Intini分享了他用来构建可扩展其应用程序的生产就绪环境的代码和过程，他现在声称该应用程序在部署环境中的停机时间为零。XMLDirector：反对DockerAndreasJung是XMLDirector的项目负责人，XMLDirector是一个XML内容管理系统和工作流平台，旨在通过转换发布格式和管理文档集合的工具来支持企业XML环境。两周前，他写了一篇关于尝试在生产中使用Docker的文章，将特定的XML类型的数据库放入容器中，以便快速安装和管理它们；将Plone企业内容管理系统应用放入容器中，用于XMLDirector的演示；并将大量特定于XML的数据库放入容器中，以便可以使用它们来测试XMLDirector的后端与它处理其他XML数据库后端的方式。可惜Docker并没有打动Jung。他发现通常的构建过程比使用shell慢5到10倍；多个进程需要重启Docker；由于Docker创建了多个图像和容器，因此在测试后删除系统上的副本需要一些操作。在尝试使用Docker无果后，Jung不得不回到“老式的部署环境”，尽管他承认Docker背后的理论和概念确实很好（尽管他说“Docker的架构和实现一团糟。Docker在生产环境中是完全不稳定的。它是不可靠的，不可预测的，不可靠的。”）准备好生产了吗？DependsDocker发展迅速，生态系统不断扩大，容器化系统正在被金融机构、媒体和其他大型跨国企业采用。尽管Docker的容器技术正迅速被公认为构建投入生产的分布式应用程序的标准，但早期采用者发现它最适合这种用例：已经考虑过如何使用微服务构建其应用程序的企业。:生产环境中的Docker
