容器在 Spotify、DramaFever、Built.io 和 IIIEPE 的使用案例分析

663 阅读12分钟
原文链接: dockone.io

音乐流服务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说。

结论

在2015年初,生产环境里使用容器对于企业而言似乎还是实验性或者大胆的选择。现在,仅仅12个月之后,容器已经不是实验性地部署到生产环境上,或者仅仅针对特定项目,而是已经开始渗透进企业的整体架构里了。

原文链接: Containers in Production: Case Studies, Part 1 (翻译:崔婧雯)
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。