最近，我花了两个星期，帮助未来的架构师和技术领导者们了解原生云架构。我们在Realscale网站上讨论了许多涉及到的概念。
其中讨论的一部分重点是将容器化作为旧版应用程序现代化的战略。部分领导者们决定使用Docker容器去建立他们项目的一部分。在这篇文章中，我将会分享他们在开始这个项目时发现的重要经验和学到的关键教训。
一切自动化
许多的开发者作出的假设是-认为他们的服务器将是运行很长一段时间。但其实他们并没有一个适当的用于恢复的自动化流程，如果他们的Docker主机 -我们以一个在这种情况下的EC2实例来举例，发生故障或终止。这包括存储在本地文件系统，而不是任何数据远程块或基于文件系统的存储。我们的生产环境的Docker容器需要确保Docker主机在故障的情况下可以被替换并能用上新的实例。这就要求服务器监控和自动化手段来确保可靠的基础设施为我们的生产中的Docker实例提供足够的业务支撑。虽然我倾向于通过使用Cloud66来实现，不过一些团队倾向于选择使用其他服务，或使用Docker Swarm或Kubernetes来管理它们。
编排您的容器
你是否认为云服务器是一种存活时间短并且转瞬即逝的资源呢？容器存活的时间通常更短。根据它们的需要，容器一般可以持续存活几秒钟或者几天或更长的时间。这其实应该已被纳入设计和实现代码的方式。如果你的代码或应用程序的配置假定了他们的环境是长期的，又或者他们所依赖的其他服务将会持续存在，那么，这有可能会带来意想不到的灾难。容器管理和业务流程的解决方案确保了有足够的容器可用，可按需扩展或收缩实例，并可以控制分配给我们的容器以及主机资源（如CPU和内存）。在研讨会期间，我们讨论了像Cloud 66如何处理这种没有任何多余的脚本的这样一种方案，帮助他们了解到了选择适合自己的目标架构供应商的会带来的好处。
一些开发人员对于容器存活这一问题认识到的有点晚，所以之前通常这么做他们的内部文件系统。我们来假设部署一个数据库 - 我们用MongoDB来做这次的举例 - 那么数据库必须挂载必要的数据文件和外部存储。否则当容器被销毁时，任何插入的数据也是如此。同样，任何重要文件必须遵循同样的限制约束。
Docker有一个很好的文档，它解释了如何运作的这方面的更多细节。
明智地选择你的数据库
我之前写过该篇文章，所以就在这里过多地讨论了。那些领导者们会发现他们的数据库平台的选择会正面或负面的影响了他们的基础设施建设和实施的需要。有些团队选择了一个key/value键/值存储例如Redis，他们只是认识到实现一些密钥聚合功能所需的工作量将可以通过选择不同的数据库来实现更好地处理。值得庆幸地是，它有可能是一个小项目并且这个问题在早期就被发现。但其实我见过的项目通常不是这种情况，它最后都花费了相当大的努力来取代最初的选择，更糟地是，那些出现的各种问题动用了许多方法和业务中断去解决。无服务状态是有戏的，但它不能代表一切，然而。。。
一些*决定探讨一个纯粹的无服务器架构。虽然他们能够解决许多使用无服务器方式的现代化需求，但是往往忽略了几件事情。这些事情包括：每个帐户的速率限制，端点和帐户级别使用情况报告，以及内置的细粒度访问控制的完整的API管理解决方案。这些和其他功能可以随着时间的推移和一些代码来克服，但大多数项目团队期望专注于功能，而不是基础设施的建设。一些*选择了混合使用Docker容器和无服务器的方法来部署他们的API管理层，要求服务器终究还是要被管理的。通过选择最佳的容器编排的方式作为我们的解决方案（如前所述），团队可以通过使用Docker和无服务器功能的组合来合并必要的基础设施。
Docker已经适于生产环境了么？
是的，Docker肯定已经适于生产环境了。许多组织都意识到使用Docker所带来的好处，像GE，ADP，等等。只要确信你肯花时间来计划你的Docker生产环境。为进一步阅读，请查看“在生产环境中Docker的9个关键决定”。原文链接：Lessons in Preparing Docker Containers for Production （翻译：薛开成）
===============================================================
译者介绍
薛开成，思杰系统南京研发中心全球实验室基础设施团队高级工程师。
原文发布时间为：2016-12-09
本文作者：薛开成
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：为生产环境准备Docker容器的有关课程