转载

容器在生产环境应用：案例研究，第一部分

音乐流服务Spotify，视频流公司DramaFever，后台即服务供应商Built.io，以及教育界智库“Instituto de Investigacion, Innovacion y Estudios de Posgrado para la Educacion”(IIIEPE) 的共同点是什么呢？它们全都使用容器运行其关键的Web基础架构。

它们的案例体现了使用微服务架构，创建web应用程序，以及在生产环境运行容器的的优势和挑战。

运行大规模全球应用程序

Spotify有全功能的主机，包括使用社交媒体身份认证登录，基于之前所听的音乐进行推荐，以及共享音乐。但是播放音乐的功能是最为重要的。要让Spotify的6000万用户满意，音乐就必须保持流畅，即使某个开发人员在专辑封面特性上制造了一个bug，或者其4个不同的数据中心里的5000多台生产服务器中的某个宕机了。

要达到这一目的，Spotify将其每个单独特性都打包成一个微服务。随后使用容器协助将其中一些微服务组合在一起，这样单次请求就能够得到所有相关信息，并且展示在用户——以及可能的订阅者——的界面上，而无需执行很多次重复的调用才能匹配上特定信息。这样的设计使得其他微服务可以同时独立地运行。

在旧金山的DockerCon 2014大会上，Spotify软件工程师Rohan Singh介绍了Spotify计划将微服务打包到容器流里，能够在全球根据用户需求进行伸缩。Singh在DockerCon上的演讲正发生在Spotify计划在生产环境里部署容器的第一周。九个月后——2015年三月——Spotify的Evgeny Goldin在Tel Aviv的DevCon现场介绍了独家秘籍，介绍容器如何作为流服务的持续交付文化的中心。

Goldin称Spotify的问题为NxM：“你有‘N’个服务，想将其部署到‘M’台主机上，”他对DevCon的听众说。

NxM问题指的是使用Spotify时会出现的规模化问题，全球用户都以自己的方式使用着Spotify，启用并停用特性，播放音乐，或者在夜间关闭应用程序的使用。因此，Spotify用户的应用程序要求特定的微服务，它发送请求给Spotify的服务器，并且得到所需数据。随着新特性的逐步添加，或者更多用户同时请求启动他们自己的应用程序服务，Spotify需要启动更多的容器来满足这些额外的需求，并且随后在不需要维护这么多服务器的处理能力时销毁掉这些容器。

要满足这样的需求，Spotify创建了开源项目Helios 。

“我们称之为Docker编排框架。它解决了一个问题，并且确实解决得很好，”Singh说。“给出主机列表和需要部署的服务列表，它就会直接完成部署，”Goldin说。

从2014年7月份开始，Spotify开始在生产环境上使用容器和Helios模型，这是Spotify可扩展战略的关键一步。“我们已经在生产环境里的上百台机器上使用，”团队在GitHub上的Helios README文件里发表了声明。“但是我们还没有接近容器使用上限，目前还不需要重新审核已有框架。”

DramaFever的视频需求

DramaFever运行白标网站，比如AMC的SundanceNow Doc Club，并且支持流网站Shudder，也有合同义务向其他流服务提供内容。Kromhout，是Pivotal的Cloud Froundry的资深技术人员，之前负责DramaFever的站点可用性，谈及她在DramaFever的经历：“我们不是Netflix，也不是Hulu，但是如果你在Hullu上看韩剧，其实看的是DramaFever拥有版权的流内容。”

在她在DramaFever的工作期间，Kromhout用“cattle, not pets”的理念来实现架构，所有请求路径上的东西都容器化，能够自动扩展和收缩。DramaFever从2013年10月份开始在生产环境使用Docker 0.6版本。使用Docker帮助实现了一致的开发以及可重复的部署过程；容器帮助保证开发人员使用的代码和配置环境是相同的，即使他们将代码从笔记本移动到基于云的QA，预生产以及生产环境上。在架构自动扩展应用程序或者微服务组件的新实例时，容器里的代码是可信任的，因为其和任何测试或者开发的环境拥有相同的操作上下文。

“2014年7月份开始这项工作时，在生产环境使用Docker说明这是令人激动的工作之所，”Kromhout说。

DramaFever在生产环境里要实现高效的自动扩展，最初必须解决的障碍之一是，构建一个健壮的容器registry。Kromhout说，在分布式架构里，经常会遇到多个容器同时启动的情况。这是动态进行的，因此架构会基于使用情况按需启动实例以及启动容器。这些'docker pull'请求发送到私有Docker registry处。registry在大概20个容器同时启动时就面临崩溃。

要解决这个问题，DramaFever在每个地方，每台本地主机上，都运行了registry的容器，这样image pull会在本地完成，同时使用AWS S3作为后台存储。

”DramaFever可以继续走向扩展的方向上，“Kromhout说。但是她说Tim Gross，DramaFever的运维总监，意识到”如果不得不扩展registry，为什么不用一种你永远都不会去想’我们的registry服务器能处理这么多次的image pull么‘的方式来实现呢？”

她承认这是一个很特别的场景，但是当你要大规模运行容器并且使用自已管理的registry时就会遇到这样的问题。Kromhout在OSCON 2015大会上介绍了DramaFever的容器故事，“ 生产环境里的Docker：可以实现，而不仅仅是口号 ”。

通过生产环境API管理容器

Nishant Patel，集成和后台即服务供应商 Built.io 的CTO，至今已经在生产环境使用容器将近两年了，他坚信这使得其产品差异化于市场里其他供应商的服务。

Patel说其中一大部分，IaaS和Baas客户的相当一部分都需要数据库即服务的解决方案，有开箱即用的认证服务和类似特性，能够将数据库作为应用程序提供给终端客户。但是20%的客户要求更为严格，需要围绕数据库封装的额外业务逻辑。Built.io的客户需要能够编写自定义逻辑，并且能够将这些逻辑添加到Buit.io的服务器上。

“我们不希望客户搭建自己的服务器等操作时会十分复杂。因此需要更容易的方式，让客户上传自己的自定义代码，并且在数据库上运行。因此，我们需要云上的容器，”Patel说。

Built.io的位于孟买的工程师团队研究了相应的可行方案，两年前，其中一个工程师试用了Docker，当时Docker还刚发布0.9版本。“我们进行了快速的观念认证，搭建容器，上传代码，我们被Docker能提供的功能深深吸引。这是一个安全的容器，不会和其他人的代码混合。因此随后我们更进一步，尝试编写自己的管理层。”

Patel估计在任何时间点，Built.io的客户会启动上千个容器，因为每个客户账户默认使用一个Docker容器。

“使用容器给我们公司带来了竞争力。我们的对手和我们的需求一致：他们也需要迎合有特别需求的20%的客户，但是因为我们使用了Docker，所以能够创建出平台即服务，而我们的竞争对手却无法做到这一点。这让我们的故事更加强大。比如，在生产环境里使用我们带有Docker的MBaaS，你可以上传完整的Node.js应用程序。”

和Spotify和DramaFever一样，Built.io发现已有工具缺失一些功能，并且很早就在生产环境引入了容器。Built.io选择构建了自己的管理层，所选的方案和Spotify构建自己的编排服务，DramaFever构建水平可扩展本地主机Docker registry的架构一样。

“我们需要的是通过API构造API调用来启动容器的能力。然后便构建了所有一切，比如，我们需要能够搭建更大容器的付费更多的客户。我们想要客户能够有负载均衡器容器，想要添加额外的安全预配，通过API管理启动和停止容器，并且使用API得到容器日志并将其放到客户的管理UI里。”

Patel说Built.io继续关注容器生态系统的其他能够负责管理层的工具，现在 Deis 正在向这个方向靠近，但是他们目前仍然决定自己做这一层。

利用容器引入持续交付

从来都不缺少想要在生产环境试用容器的公司，Luis Elizondo发表了关于其Docker生产工作流的一系列博客文章之后发现了这一点。Elizondo在IIIEPE工作——一家政府资助的专注于教育研究的代理商——在这里他管理所有东西，从小型静态HTML站点到教师使用的成熟的学习管理系统。

“我们有25个web应用程序，其中大部分运行在Drupal上，但是我们也使用Node.js和Python。最大的问题是当我们将一个web应用程序从开发环境移动到生产环境时会遇到很多问题，”Elizondo说。

Elizondo正在寻找能够帮助它们水平扩展的私有云基础架构方案。他们预计其web应用程序在数量和使用上都会增长，因此Docker是基础架构解决方案的极有吸引力的选择，可以随着可能的增长而扩展。

同时，IIIEPE在其应用程序架构里还没有使用持续交付方法论，使用Docker容器基础架构也能让他们借此实现新的持续交付工作流，和编排流联合在一起。

Elizondo的博客系列文章讲述了生产环境里存储，编排，服务发现和负载均衡的方案，并且分享了在让工作流能够上生产环境的过程中所采用的workaround和解决的问题。

团队有两个服务器。一个运行MaestroNG，并且负责启动stock Docker容器。另一个运行着带有Jenkins的虚拟机。“我们将其作为执行重复工作的机器人来使用，”他说。“我们在Jenkins上编程，这样当新改动push到任何项目中时，Jenkins会监测到这个新改动，重新构建整个image，给新的image添加代码，然后命令MaestroNG从Docker Hub上pull image，这就是基本的工作流。”

Elizondo在2014年底使用DigitalOcean平台来测试新架构和容器工作流，很神奇地，仅仅花费了一个半月就完成了测试。

“在我们实验里最大的发现是在容器里，以及在Git repo里，该工作流不仅仅适用于Drupal，”他说。“它还适用于Node.js应用程序。我还测试了Ruby应用程序。因此这是一个标准的工作流。任何人都可以使用。”

在生产环境里使用Kubernetes管理容器复杂度

对于Elizondo来说，生产环境里的容器方案是Docker。Elizondo说他也试验了Kubernetes，但是发现对于他的需求而言Kubernetes太复杂了。但是对其他人，比如电子商务巨头ZUlily的核心工程师团队来说，选择是相反的。根据Wall Street日报的Rachael King所说，Zulily首先在2014年5月开始在生产环境上试验容器。King报告Zulily的软件领导人Steve Reed在2015年7月的OSCON说“最艰难的部分是操作容器，特别是在生产环境里。”

当第一次评估生产环境里容器的优势时，Zulily选择搁置了基于Docker的生产环境方案，因为这样方案存在内在的编排上的复杂度。现在使用了成熟的Kubernetes平台后就能够管理Docker容器的编排，于是Zulily已经重新开始实现其生产环境的目标了。“Kubernetes已经可以用在生产环境上，即使对于像Zulily这样的部署而言，我们谈论的可不是仅仅数百个节点，”Reed说。