本文讲的是生产环境运行Docker的9个关键决策，【编者的话】生产环境运行Docker并没有想象的那么简单，如何实现稳定安全的部署和扩容? 又有哪些需要考虑的关键决策? 本文就此做了一些分析和阐述，赶紧来看看吧！

也许你已经构建好了你的Rails或者基于Rack的Ruby应用。它甚至在你笔记本上的Docker容器里运行着并且团队里的其他开发者也是这样将它跑起来的。一切看上去棒极了，那么或许是时候装载它了。

不过，等一下！别急！将应用切换到生产环境中的Docker运行并没有听上去那么简单。这里面要做的可不仅仅只是将你本地构建的容器镜像装载到生产环境而已。

让我们一起来看看，在你可以安全地将容器化的Rails以及基于Rack的Ruby应用部署到生产环境之前你将可能面临的9个最主要的关键决策。

关键决策 #1：镜像管理

在开发环境里为构建镜像而设置一个Dockerfile及docker-compose.yml是相当简单的，因此在生产环境里你也应当创建一个一致的流程来构建Docker镜像文件。这将可以消除对本地环境的任何顾虑，避免了依赖于开发环境笔记本来作为你构建新镜像的唯一手段。它还使得你可以创建一个不用开发团队手工干涉的从代码提交到Docker镜像的持续部署管道。

除非你打算将你的Docker镜像对外公开，否则的话你可能还需要一个私有的Docker镜像仓库。虽然Docker官方提供了一个私有镜像仓库允许你自己来部署和管理镜像，然而，你可能并不愿意采用它，毕竟如果它发生故障的话会打断你的发布流程。你将需要选择一款方案来加固私有Docker镜像，同时还得保证在构建和部署过程中可以访问到它们。

关键决策 #2：选择一个云服务提供商

一旦你已经拥有了一个Docker的镜像，你需要做的便是将它部署到一台Docker宿主机上。许多云服务提供商如今已经加入了对Docker容器部署的支持。由于这里面大多数是根据所使用的资源而不是容器实例来收费，怎样核查定价细节以避免天价账单就显得至关重要了。

请注意，如果容器的部署过程横跨多个云服务提供商的话，这可能会造成将来变更云服务提供商变得更加困难。如果你希望使用多个云服务提供商或者想防止被圈死的话，你将需要做的是建立对多重云服务提供商的支持（或者找到一个支持这样做的解决方案）。

关键决策 #3：网络访问和安全补丁

在本地开发环境里运行的容器不会有严重的安全风险。所有进程都运行在单台主机上，生产服务器上常见的网络入侵风险以及各式各样的攻击载体均被隔离开来。

在开发期间为了便于排障，开发环境的配置一般是相对开放的。而在生产环境里，网络的配置则需要考虑更多方面。公网流量不应该有访问某些容器的权限，而应该只有内网的其他容器才可以访问它们。通过对网络流量的监控，暴力登陆攻击，以及其他的攻击载体必须被识别出来然后妥当地处理掉。

此外，你还得在安全补丁发布后及时跟进，然后判断你的宿主机和容器是否依然都是安全地还是需要将补丁打上去。

将你的容器挪到生产环境的话需要考虑网络访问以及如何保证容器和Docker宿主机能及时地打上安全补丁等问题。对于生产环境而言千万不要忽视这一关键步骤。

关键决策 #4：容器和宿主机之间的负载均衡

一旦从单个的容器服务转到跨越一个或多个宿主机的多个容器，我们便将需要对应的负载均衡器来分发传入的请求。常见的做法是使用像nginx或HAProxy这样的工具来实现。难点主要在于需要保证当容器创建或销毁时它们的配置能够及时更新，为扩容而添加到生产的新Docker宿主机也是如此。你可以及时通过工具或脚本来满足这类需求。

需要注意的是，除非你打算在更新后将现有的部署下线，否则你将不得不支持应用服务同一时间多个版本同时运行的情况。你的负载均衡策略需要将这个计算在内，以防止用户连接的丢失又或者是将流量路由到错误的版本。

想了解更多关于如何选择负载均衡策略的信息的话，欢迎阅读我们在服务器扩容技术方面的文章。

关键决策 #5：部署过程

许多开发者认为那些他们在开发环境里用到的工具也将在生产环境里工作。不是这样的。Docker Compose的配置从开发到生产将会有很大的不同。从卷的设置到端口的绑定以及网络的配置，布设容器的方式会发生变化。由于挪到了多宿主机的环境复杂度也会相应提高。你可能还需要一些在开发环境不常见的额外容器，例如日志聚合器，外部数据库，以及高可用的消息代理（仅仅列举几个）。

协调不同环境配置之间的差异也需要相当大的脚本化的努力。这可不会像它在开发环境里docker-compose up那么简单。你需要留出足够的时间来解决这些细节问题，因为你已然从一个简单的，单个容器应用转变为一组复杂的容器镜像，每个对应多个实例，并且它们需要被布设到负载均衡器后面以分发处理工作负载。随着你的应用不断地更迭以及流量的提升，还将采用滚动升级(rolling upgrades)或者蓝-绿部署(blue-green deployment)等策略以防止站点故障。

不太了解有哪些有效的部署策略？可以查看云原生应用的发布策略这篇文章来了解更多。

关键决策 #6：服务发现

随着容器数量的不断增长，也就自然带来了额外地管理他们的注册以供应用消费的开销。业界有多种工具可以用来管理这个流程，大多数需要集成和配置到你的Docker生产环境里。与此不同的是，Cloud 66找到了一个更为简单的管理服务注册中心的方式，那便是利用内部的DNS服务器来实现。

无论你选择的是哪款方案，都得确保你的服务注册和你的容器实例同步，并且在容器扩展到多台Docker宿主机的时候在负载均衡策略方面有所响应。这样做将可以保证你的应用可以编码成一个通用的服务名称（例如myservice.mycluster.local），它可以用来将请求路由到特定的容器实例服务。

关键决策 #7：日志管理

在开发环境里使用Docker Compose的话可以看到详细的日志输出并且可以快速的排障。而切换到跨越任意数量的宿主机的多个容器实例的场景时，这便会变得更难去排查宕机问题。

分布式日志策略使得服务器可以从一个或多个的日志服务器上采集和聚合日志记录。生产环境的基础设施也将需要支持跨越容器的日志聚合。你还得考虑该如何规划查询和搜索这些日志来配合排障等因素。

关键决策 #8：监控容器

在生产环境里对容器的监控是必不可少的。从Docker宿主机到容器，你需要知道每个服务及整体系统的健康性。选择正确的工具和监控策略可以确保你尽可能地减少中断的影响并且最大限度地提高主机资源利用率，从而改善用户的体验。

不知道你需要什么样的监控策略？我们有一份监控策略指南也许可以帮到你。

关键决策 #9：数据库管理

在开发环境，数据库可以托管在容器里而无需担心I/O性能方面的问题。生产环境则无法容忍糟糕的性能，尤其是当我们想交付的是绝佳的用户体验的时候。根据需求扩展数据库以处理日益增长的I/O，配套高可用和可靠的备份/还原策略是成功运行一个现代Web应用或者移动端API的关键所在。生产环境所选择的策略将会对你的用户产生积极或消极的影响。

你可以阅读我们关于扩展生产环境数据库的文章来了解更多内容。

我真的需要马上做出这些决策吗？

是的，很有可能。除非你正要部署的是一个只有小流量访问的简单应用或者API，否则的话这里面的每个决策都将会是影响产品成功的关键。看上去有一点担子，不是吗？

开发人员需要记住的是Docker是一款工具，而不是一个全面的云原生应用架构的解决方案。它提供了一些精彩的功能特性，并且我很高兴能够将Docker作为我的基础架构的一部分。但是，它同其他基于云的解决方案一样需要付出同等的努力（甚至大概还会多一些）来维护一个生产环境的Docker部署。

使用Cloud66在生产环境里管理容器的话则无需再有这些方方面面的无穷顾虑。通过自定义一些配置文件，我可以将我的环境从开发迁移到生产并且获得他们平台提供的所有好处：内置的日志，安全的网络访问管理，监控，持续交付，补丁管理，以及他们按需提供的数据库即服务（Database-as-a-Service）。

亲自去尝试一下吧，看看部署及管理自己的Docker生产环境究竟能变得多简单轻松！

原文链接：9-crtitical-decisions-needed-to-run-docker-in-production （翻译：吴佳兴)

原文发布时间为：2016-05-12

本文作者：colstuwjx

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：生产环境运行Docker的9个关键决策