转载

一个非营利性的Docker案例

即使是在和那些非常熟悉Docker的讨论时，我发现很多人也坚信它只适用于大规模扩展的用户场景。这是事实，Docker是在任何层面上应对服务扩展的完美工具，并且也是微服务架构的理想工具。但它的的价值并不仅仅与此。

在本文中，我将展示Docker从相反方向应用的价值。不同于服务扩展的用户案例，今天让我们来讨论下缩减的。

单体应用vs隔离干扰

我在一个叫做SIL International的非营利组织工作，在此我负责领导我们的IT应用开发团队。作为IT开发部门，我们负责数十种主要为全球内部用户使用的应用程序开发。相应的，很多我们开发的应用程序都是基于同样的技术。

由于我们只有很少的预算（就像大多数的非营利性机构一样），我们认为运行大量我们的应用程序最便宜和最简便的方案是集中部署在同一服务器上。这导致了大量单体应用程序纠缠在一起，它们运行的web应用，它们的数据库，以及其他随机服务都在同一服务器上。

以今天的标准来说，所有人都会同意这不是一个好的运维方式。

因为一个应用程序的问题会影响到其他的应用程序，我们决定增加投资以隔离各种干扰以及迁移各个应用程序到相应的一系列服务器上。与此同时，我们也考虑过这样是否会更省成本，即迁移到云上而不是运行和管理我们自己的数据中心。经过多种成本比较和参考其他非营利性组织的情况，我们决定迁移到Amazon的云上，并利用OpsWorks来帮助实施自动化。

最初时，它们进展的非常好。我们迁移了多个应用程序以及相应的技术栈到OpsWorks。我们的开发人员非常享受我们实现的自动化部署，并且我们的运维人员也非常满意不必再支持服务器的维护以及分离的应用服务。然而，最终却走向了我们所未预期的更高成本，以及更低资源使用率。

由于我们的用户群很小且分布在各个不同的时区，所以我们看到的是服务器一贯的低使用率。我们的每一个OpsWorks栈都包括一个弹性负载均衡，一个NAT服务器，一个微型EC2实例，一个微型RDS实例。

这个问题很复杂，因为我们也想要一个模拟环境（staging environment，即在软件最终发布前，开发或者设计人员对软件进行调整后可以及时预览改变的测试环境，这个环境更接近于产品最终发布后的运行环境），为每个应用程序真正分配其中的两个栈。同时我们也想要在模拟环境中分享这些资源，但是基于OpsWorks每个栈都只运行在各自的虚拟专用网络内，所以资源都是彼此分段隔离的。

基于一年服务的定价，这种配置大约需要花费每个栈800美元或者每个应用1600美元。这确实解决了我们的干扰隔离的问题，但是它太昂贵并且感觉太浪费了，因为我们的服务器几乎是24/7的空闲着。

高密度服务器

是否有一种方案能让我们的应用程序保持隔离，同时获取更高效的资源利用率？假如有的话就太好了。

Docker登场

就像其他爱好者一样，当我们在数年之前抓住了Docker的风潮时，我们就开始学习它。所有内容听起来都非常棒，但看起来并不适用于我们，因为我们并没有服务扩展的需求和问题，并且我们大多数的应用程序并不是基于微服务架构实现的。

偶然的，我们意识到Docker既然可以方便的支持扩展那么它也可以非常方便的应用于缩减。这导致我们开始向Docker迁移。

现在我们在AWS上使用它们的EC2容器服务运行了很多基于Docker的应用程序，我们应用程序的平均计算量和内存使用率大概是一个微型实例的1/6到1/4，运行状况良好。我们现在又为每个应用程序增加了备份实例，用于增强负载均衡以及服务可用性的提高，以及降低成本。

由此，我们获得我们所购买的服务器更好的利用率，并且我们可以以我们所期望的粒度隔离我们的应用程序。我们现在能够运行一系列的Docker主机服务器集群在一个单一的虚拟专用网络内，所以我们可以在需要的地方适当的共享服务及隔离干扰。

例如，我的团队的模拟集群有一个弹性负载均衡器，一个NAT实例，一个RDS实例，四个小EC2实例，用以支持19个应用程序。所有的这些花费一年大约1,200美元。因此，每个应用程序的成本大约是每期63美元。这比一个专用OpsWorks堆栈800美元要好得多。

在我们的生产环境中，每个应用程序得到一个专用的弹性负载均衡器和RDS实例以避免单点故障。因此，每个应用程序的成本上升了一点，但它仍然低于使用专用的堆栈，因为它们可以共享一个NAT实例。

我们不但可以节约成本，同时得益于冗余实例提高了我们的服务可用性。

这不仅仅是关于钱，我非常理解成本是很多决策的重要考量因素，就像人们不断往Docker迁移的主要因素就是成本，当然也有一些其他无形的原因。