本文作者为ContainerShip联合创始人Phil Dougherty，ContainerShip是一家提供跨云服务的云服务提供商，在成立ContainerShip之前，Dougherty在上一家公司中曾经历过系统容器化和分布式化的过程，作者认为那是一段痛苦的经历，本文总结了那段过程中的经验，作为容器托管需要注意的六大事项分享给大家。
以下为译文：
除非你在过去几年里一直生活在石器时代，否则你肯定知道容器和Docker。如果你是互联网极客的话，可能你已经准备在生产环境中使用Docker了。
1年前我也在尝试跟上技术更新的步伐，但以忙于交付原生态的系统结束。我见识到的虽让我某种程度上伤痕累累，但也让我收获颇丰，更重要的是让我意识到很多很流行工具的缺点。直到我们建立起一套不错的托管技术栈的时候，我的团队已经为融合这些技术开发了很多定制代码，我对这样的系统设计和运营很不满意，于是离开那里，成为了ContainerShip的联合创始人。
显然我可能带有偏见，但我认为ContainerShip非常棒，它可以帮你节省很多时间，减少很多痛苦。当然，我不会强迫你去用它，同时我也会尽量避免将偏见带入这篇文章中。
1太多不确定因素
微服务和面向服务的体系模式，倡导将系统分隔成许多不同的、小的、松耦合的软件模块，而不是一个单一的整体。当涉及到开发一个大型软件项目时，更容易将这些模块分给不同的团队，每个团队还可以用自己擅长的技术来开发。
这种认识甚至已经渗透到了基础设施的层面。取其精华，去其糟粕，这在理论上讲行得通，但实践过程中可能是个美丽的陷阱。
当您的托管平台是由一系列变动的部件构成，每个部件都是由开源项目或公司所维护，就需要编写大量的定制代码来将其融合起来。而这些定制代码，必须要自己维护，并且当问题发生时，你很难确定是哪一个组件的故障，可能也没人能帮得上忙，因为让团队成员学习大量的组件是非常耗时和困难的。如果API发生变化或新版本发布，你只能靠自己让它继续工作。
我最初是沿着这条路走的，一个基础设施团队，服务于数百个非常忙碌的服务，最终以痛苦告终。
2没有高可用性
现在有几个越来越受欢迎的开源项目，完全忽略了它们master服务器（编排管理剩余集群的服务器）的高可用性。可怕的是这些公司宣称其产品是在生产环境中运行Docker的最好方式。如果集群管理系统不是高可用的，没有leader election的概念，运行在一台单独的服务器上，我不能想象这可以称为生产级别的产品。无论选择何种解决方案，请确保它支持多个master的高可用性，以及通过一些选举机制来决定哪个master作为leader或者有很好的结束机制。
3不开源
我曾因为把宝都压在一个非开源项目中，而非常痛苦。如果没有类似经历的话，可能会觉得难以置信。以Genius上所纰漏的Heroku的丑闻为例，没有人会想到，他们底层的托管平台的文件会有造假，用户则在被系统超长的响应时间所困扰。还有很多古怪事情发生在这些非开源的Docker管理系统。
4非必要的网络需求
现在有一个趋势是通过overlay网络，为主机系统上的每个容器分配唯一的IP地址。这种方式带来的最大好处是易于使用，但随之而来的是延迟和带宽限制的成本。甚至一些最专业的container编排系统也在向用户推销这种方式。在新的实现中，事情得到了改善，但是降低性能来提高易用性的方法，并不是一个好主意。
另一种方式是“端口映射”，比如所有容器都运行子啊随机端口上，通过计算获得流量的正确方向。好消息是，端口映射问题并不是真的很难，你不需要限制你的性能。使用分布式架构的目的是上提高性能，可用性和功能，不要因为错误的选择反而破坏了性能。
5托管核心业务
几乎所有大型云供应商都发布了自己的容器生产解决方案，比如AWS的EC2 Container Service，谷歌的Google ContainerEngine，Joyent的Triton等等。不幸的是（我的观点），在容器托管服务商中运行你的容器负载，会违背容器最大的一个好处：可移植性。托管服务供应商会想尽一切办法留住你。过去你没有太多选择，只能纠结于配置管理系统和多个提供商的API。现在情况已经有所转变，有了开放的和供应商无关的选择。我强烈建议不要使用一个不具有灵活性的系统，而且与供应商无关作为他们的主要目标。
另一个选择是“Docker as a Service”提供商，在他们自己的网络上提供运行所有重要的系统，而且为你提供托管主机上简单的运行独立服务器，有客户端连接到他们管理系统。但当你不想再付钱给这些供应商，或者他们的服务不再适应于你业务的增长时，你是没有办法回退到免费和开源的模式的。ContainerShip可以做到，当您在CoutainerShip中启动一个集群，系统的核心运行在您自己的服务器上，您可以随时停止运行在云服务中的工作，使用开源的核心系统。
6强制的操作系统
我以前负责安全和PCI DSS协作，还要处理随之而来的上百的监控和审计要求，使用微型Linux操作系统是不行的，因为IDS／日志／安全软件，不适合在只能通过Docker安装和运行软件的主机上使用。可能对你来说并不是一个问题，但我希望能自由选择操作系统。为什么要用一个指定的操作系统来使用Docker？或者为什么你需要利用一个初始化系统来运行容器？我认为这是你要极力避免的紧耦合。灵活性和多种Linux操作系统的支持非常重要，尤其是对于那些希望能够继续使用某些操作系统的企业，因为他们已经在这个操作系统上投入了时间培训，有一些服务部署在上面。
总结
以上只是我的建议，但它们来自于无数个小时的研究，开发和实践中大规模运行Docker的经验。当你计划向容器和分布式系统迁移时，请记住这些经验。有时候，炒作会让你走上一条路，从现在起6个月就没办法工作了。计算领域的技术更新非常迅速，但多年沉淀下来的最佳实践不会改变。一定要相信你的直觉，容器并不能使一个坏的解决方案变好。
原文发布于微信公众号『Container技术日报』，欢迎关注！
