生产环境运行Docker的9个关键决策

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文作者：colstuwjx

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

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