嵌入式Linux中文站

Netflix是如何针对云构建和部署代码的


2008年秋季,Netflix遭遇了一次严重的数据库故障,连续3天无法向成员寄送DVD,从那时起,他们决定向云迁移。今年2月,Netflix宣布完成了向云的迁移。

而与之相应的是,Netflix的开发工作也要针对上云做很多工作。那么,Netflix的代码在部署到云上之前,是如何构建的呢?

Netflix的三位工程师Ed Bukoski、Brian Moyles和Mike McGarr撰文介绍了相关的工具与技术。

Netflix之前已经开源了其持续交付平台Spinnaker。Spinnaker可以快速可靠地将软件变更发布到多种云平台。

从上图可以看到,很多工作是依托Spinnaker平台进行的。

一行代码在进入Spinnaker之前,还要经过很多步骤:

  • 在本地使用Nebula构建和测试
  • 修改被提交到一个中心git仓库
  • 使用Jenkins作业执行Nebula,构建、测试和打包应用,准备部署
  • 将构建“baked”到Amazon Machine Images中
  • 使用Spinnaker流水线部署和提交代码变更

关键词:文化、云和微服务

Netflix是一家非常强调“文化”的公司。其中有一点是“Freedom & Responsibility(自由与责任)”。该文化激励和促使工程师使用自己感觉最适合的工具来完成任务。如果一个工具广为接受,它肯定是很有竞争力,能够带来巨大的价值,并减少大部分工程师的整体认知负荷。团队可以自由地实现替代方案,但也有责任维护这些方案

另外两个关键词也不难理解,前面我们提到,2008年开始,Netflix开始向云上迁移,一体化的、基于数据中心的Java应用转向基于云的Java微服务。

下面就具体看一下代码部署步骤。

构建

Nebula是Netflix开发的Gradle插件集合,可以让开发者更方便地使用Gradle构建、测试和部署项目。也已经开源。

Gradle为构建、测试和打包Java应用提供了很好的支持。之所以选择它,是因为方便编写可测试的插件,还能减小项目构建文件的大小。Nebula通过一些插件在依赖管理、发布管理和打包等方面扩展了Gradle。Nebula提供了可复用和一致的构建功能,同时减少了每个应用构建文件中的样板代码。

集成

代码在本地经过Nebula构建和测试之后,已经为持续集成和交付做好了准备。第一步是将更新后的源代码推送到某个git仓库。变更提交会触发一个Jenkins作业。

最早,在Netflix的数据中心中,只有一个大规模的Jenkins主节点,而现在,他们在AWS中运行着25个主节点。Jenkins被用于很多自动化任务,不单是简单的持续集成。Jenkins作业会调用Nebula来构建、测试和打包应用代码。根据所构建内容的不同,Nebula还会构建出.jar文件、Debian或RPM包,并根据配置发布到相应位置。

Bake

Netflix的部署策略是围绕Immutable Server (不可变服务器)模式进行的。为避免配置漂移 (configuration drift) 并确保部署可以从源代码重复进行,线上修改应该尽量避免。所以每次部署都会创建一个新的Amazon Machine Image(AMI)。

为从源代码生成AMI,Netflix创建了Bakery。Bakery提供了一个API,支持全局创建AMI。Bakery API服务会在工作节点上调度真正的bake作业,使用Aminator来创建Image。

在Jenkins作业成功完成时,通常会触发Spinnaker流水线。Spinnaker会读取Nebula生成的操作系统包,并调用Bakery API来触发bake。

部署

一旦bake完成,Spinnaker就可以将生成的AMI用于部署了。

未来探索

Netflix希望进一步改进开发者的体验,做得更好。目前还面对一些挑战。

一个是积极解决二进制文件的依赖。Nebula提供了简化Java依赖管理的工具,不过还有很大的改进空间。

另一个是bake时间。

随着Netflix的不断增长,很多非JVM语言应用也越来越多,像JavaScript/Node.js、Python、Ruby和Go等,最好能有一套语言无关的方案和工具。

本文永久更新链接:http://embeddedlinux.org.cn/emb-linux/industry-news/201603/20-5128.html



分享:

评论