客岁11月，Netflix开源了他们的连续交付平台Spinnaker。Spinnaker是一个连续交付平台，它定位于将产物快速且连续的摆设到多种云平台上。为了进一步相识Spinnaker及其开源近况，InfoQ与来自Netflix的Spinnaker团队举行了一次访谈，受访者包罗负责交付工程的司理AndyGlover，以及高级软件工程师CameronFieber和ChrisBerry。
Netflix客岁将他们的连续交付平台Spinnaker作为开源项目举行了发布。Spinnaker答应利用者通过创建管道（pipeline）的方式显现一个交付流程，并实行这些管道以完成一次摆设。Spinnaker可以或许向前兼容Asgard，因此无需一次性完全迁徙至Spinnaker。
用户可在Spinnaker中从创建一个摆设单位（比方一个JAR文件或是Docker镜像）开始，直至将应用摆设至云环境中。Spinnaker支持多种云平台，包罗AWS、GoogleCouldPlatform以及CloudFoundry。Spinnaker通常是在一个连续集成作业完成之后启动的，但也可以通过一个cron作业、一个Git库大概由其他管道举行手动触发。
Spinnaker还为用户提供了管理服务器集群的功能，通过应用视图，用户可以对新的服务器组、负载均衡器以及安全组举行编辑、规模调解、删除、禁用以及摆设等操纵。
Spinnaker是由基于JVM的服务（由SpringBoot和Groovy所实现），以及由AngularJS所创建的UI所构成的。
6年前，Netflix率先将服务摆设到了AWS上，为此，他们开辟了一系列工具，此中一个基于AWS的主动摆设平台：Asgard。1年前，Netflix开始了Spinnaker，以实现内部的端到端连续交付。作为Asgard的更换，该项目盼望重修一个连续交付平台，可以或许实现：
通过机动和可设置的管道实现可重复的主动摆设
提供一个全部环境的全局视图，一个应用程序可以望见本身的在所属管道中的状态
通过同等且可靠的API，提供可编程设置
易于设置、维护和扩展
兼容Asgard特性
同时，Spinnaker作为云平台摆设工具，Spinnaker团队和Google、微软、Pivotal等公司相助，致力于提供在多种平台上实现开箱即用的集群管理和摆设功能。如今，Spinnaker可以摆设管理AWS和Google云平台（GCP），针对Azure等平台的支持也在举行中。
Spinnaker重要包罗2块内容，集群管理和摆设管理。
集群管理功能，重要用于管理云上的资源。集群管理将云上资源做了逻辑分别：
呆板组：呆板组是Spinnaker管理资源的单位。呆板组标识了呆板实例，而且关联了一个负载均衡器和安全组。每个呆板组都拥有独立的设置信息（如呆板帐号等）；
安全组：安全组界说了网络访问权限，也就是一样平常意义上的一组防火墙规则；
负载均衡器：负载均衡器用于将网络流量重定向到呆板组中的呆板实例，负载均衡器还可以指定一系列规则，用于对呆板组中的呆板实例做康健查抄；
集群：集群是由用户界说的，对呆板组的逻辑分组；
摆设管理功能用于创建一个连续交付流程。摆设管理的核心是管道，在Spinnaker的界说中，管道由一系列的阶段（stages）构成。管道可以由Jenkins、定时器、其他管道大概人工触发。同时，管道可以设置参数和关照，可以在管道一些节点上发出消息。Spinnaker已经内置了一些阶段，如实行自界说脚本、触发Jenkins任务等。
为了进一步相识Spinnaker及其开源近况，InfoQ与来自Netflix的Spinnaker团队举行了一次访谈，受访者包罗负责交付工程的司理AndyGlover，以及高级软件工程师CameronFieber和ChrisBerry。
InfoQ：Spinnaker发布已经有一个多月了，社区对此的反响怎样？
Glover：社区对Spinnaker的采取程度令人震动！这个平台内置了对多个云提供商的兼容，而且可以或许通过一种可扩展的模子接入此中。这意味着我们打造了一个大型社区，而不是一系列专注于差别分支的微型社区。这种方式的上风在于社区中的每个人都可以利用各种创新的特性。我们已看到很多来自于新社区成员的pullrequest，而且我信托，随着我们继承提拔项目标可适配性，将会看到越来越多的贡献。
InfoQ：很多云提供商好像都发起利用者上传单一的摆设文件，并通过他们的API或UI举行扩展。Spinnaker的差别之处又表现在那边呢？
Fieber：Spinnaker保举利用不可变底子办法风格的摆设方式，它提供了对各种云提供商（AWSAMI、GoogleCompute
EngineImages等等）的镜像格式的原生支持。Spinnaker还支持通过QuickPatch举行已排编代码的push，让团队可以或许快速地迭代，在现有的实例中举行软件包的推送以及安装，从而减免了新假造机上线的等待时间。常见的利用方式是快速地摆设一个测试环境以运行测试，或发布一些有状态服务，比方数据存储的补丁。
InfoQ：你知道是否有效户已经开始利用Spinnaker对多个云环境举行摆设吗？
Glover：我知道有一家非常闻名的公司已经在多个云提供商环境中举行摆设了，不外他们盼望我不要提起他们的名字。我以为应该有其他用户也会如许做，而且随着社区的发展，我们将进一步相识有哪些公司将采取多个云环境的战略。
InfoQ：你怎样比力Spinnaker与Heroku的管道特性？
Glover：我以为Spinnaker与Heroku的管道相比最大的区别在于：（1）Spinnaker支持多种可适配的摆设端点，比方AWS、GCE、PivotalCloudFoundry等等。（2）Spinnaker的管道模子非常之机动，它支持多种差别范例的阶段（stage），而且社区也可以自行开辟各种管道并将其接入Spinnaker平台。Heroku管道的计划目标是为了Heroku本身服务的，而且他们的管道模子非常僵化。另一方面，Heroku的管道是通过下令行驱动的。我们如今还没有发布Spinnaker的下令行客户端。
InfoQ：从Spinnaker在GitHub上的项目来看，“gate”这个项目好像是由Groovy编写的，而且利用了SpringBoot。为什么你们选用了Groovy而不是Java8呢？
Fieber：Spinnaker着实就是Asgard项目标后继者（我们尚有一个名为Mimir的内部工具。译注：Asgard与Mimir都泉源于北欧神话），他们都是由Grails编写的应用。我们团队对于Groovy有充实的相识，感觉它比Grails更为轻量级，而且更专注于操纵性，因此值得投入精力举行研究。Spring
Boot是一种很天然的选择，而且Groovy很得当应用在这个环境中。由于选择了Groovy，我们就可以或许从Asgard中选取颠末了充实测试的AWS代码并在Spinnaker中重用。
InfoQ：Spinnaker的UI项目“deck”是由AngularJS（1.4版本）编写的，你们的开辟过程是否顺遂？
Berry：刚开始的时间是比力顺遂的。当我们在18个月之前启动这个项目标时间，Angular表现得非常稳固。而且有大量的库（UIBootstrap、UIRouter和Restangular等等）让UI可以或许非常快速地举行创建与迭代。React也是一门非常冲动民气的技能，但当时它才刚刚出现不久，而且它的规范与模式还没有Angular那么充实。
但随后这个开辟过程渐渐变得令人痛楚起来。此中部分缘故起因在于Netflix的规模很大，我们某些应用必要在一个屏幕中渲染上千种元素，而Angular1.x在处理惩罚这种数量的DOM节点时性能跟不上。对于这些页面，我们选择以纯JS举行重写，再用一些比力粗糙的方式举行性能对比。终极发现纯JS的结果可以或许满意性能的要求，即便一次性渲染几千个实例也没题目。但这种方式写出来的代码非常脆弱，毕竟Angular已经为你完成各种任务铺平了蹊径。
另一个困难在于怎样让UI实现模块化与可适配性，让差别的云提供商可以或许按照他们的需求创建UI模块，而且让外部用户可以或许创建自界说的管道组件。我们在这两方面的工作做得还可以，它不算很差，但也绝对谈不上出色。我们从UIRouter中直接抄用了大量的代码与概念，让我们的代码可以或许运行起来，但除了我们团队之外，我并没有看到像Google、微软和Pivotal实行开辟任何自界说的实现。我想肯定有某些人已经在做这件事了，只是我们还没看到罢了。
以上这些并不是说我们对于选择Angular1.x感到悔恨。在当时来说，它对于我们确实是精确的选择。如今回过头来看，假如我们可以或许回到18个月之前，那我们大概会对代码举行一些重写，但大概还是会用Angular吧。
InfoQ：你们是否筹划将UI项目迁徙至Angular2？
Berry：我们确实有举行迁徙的筹划，但估计要到5至6个月之后才会开始。毕竟Angular2还只发布了beta版本，而且在工具方面也缺乏支持。那些编写UI特性的非Netflix用户有很多都不是专职的前端开辟者，我们盼望确保他们可以或许轻易地找到构建特性的精确方式，而且在碰到题目时可以或许方便地举行调试。
我很乐于看到Angular2在来岁的发展，而且想多相识一些从1.x迁徙至2的案例。我们只是想对此采取一种相对审慎的态度，而且从其他人身上多学习一点履历。
InfoQ：Spinnaker是怎样改善Netflix的摆设工作的？
Glover：起首，也是最紧张的一点是它为全部人提供了一个标准的交付平台。Spinnaker让用户可以或许方便地举行交付，而且对于流程具备充实的信心，这正是团队最必要的东西。通过这个平台，整个Netflix服务可以或许更频仍地举行摆设，而且在运维上具备更大的弹性。
Spinnaker本身与来自Netflix的大量其他服务与工具举行了集成，使这些特性更易于为用户所用。举例来说，我们有一个名为ACA（AutomatedCanaryAnalysis——主动化金丝雀分析）的内部服务，这是由Netflix的另一个团队所维护的。只管云云，它也是一个原生的Spinnaker管道阶段，可以或许提供测试服务。在Spinnaker出现之前，假如有哪个团队必要利用ACA，就不得不自行探求将ACA集成进本身的管道的方式。
如今随着Spinnaker的出现，就为ACA的利用界说了一种标准方法，这也终极使ACA的利用得到了突飞猛进式的增长，这也进步了我们在AWS上的生产环境的可靠性。假如新创建的工具与服务可以或许提供更好的测试、数据收罗或运维的弹性，就可以将它们接入Spinnaker平台，让每个人都可以或许充实利用这些工具与服务。
InfoQ：你对Spinnaker的哪个特性最中意？
Glover：Spinnaker支持一种表达式语言，可以或许让用户对管道举行参数化。它答应用户创建一些非常复杂的管道，最紧张的是还可以或许举行重用。它们可以或许在环球范围内举行构建的提送（promote）、测试与摆设。
InfoQ：你对于Spinnaker尚有什么想增补的吗？
Glover：固然Spinnaker是由Netflix所开辟的，但是这个项目标乐成离不开与Google、微软、Pivotal和Kenzan精良的相助与他们的贡献。我们如今的精良发展状态以及将来的发展远景让我们非常奋发。我们如今正在开辟的内容包罗对容器更深层的支持、团体可适配性与机动性的增长、以及UI和UX的改进。而Spinnaker社区的发展也让我们以为非常冲动。
GregTurnquist是来自Pivotal的高级软件工程师，他在一篇博客文章中形貌了Spinnaker怎样与CloudFoundry举行连合工作。我们很有爱好相识其他人是怎样整合利用Spinnaker的。
InfoQ：你在什么机遇下会发起CloudFoundry用户实行利用Spinnaker举行摆设工作？
Turnquist：对于CloudFoundry的支持是在Spinnaker的master分支中开辟的，此中包罗大量的特性。我们如今正在筹划通过活泼的客户举行beta级别的测试。在我看来，这对于CloudFoundry的用户，无论是PCF、PWS还是其他CF的认证明例都已经成熟了。
假如你以为如今手动将新的版本发布到CF的时间太长，而盼望转而利用管道举行摆设、冒烟测试与验证，那么如今正是利用Spinnaker，剔除你的发布流程中低效部分的机遇。
InfoQ：Spinnaker可否轻便地与CloudFoundry举行整合？
Turnquist：我以为“轻便”这种表述大概不敷正确，这个词好像暗示着整合这两个平台只需很少的工作。实际上我花了很多时间去学习Spinnaker的底层概念，并将这些概念与CloudFoundry的概念举行逐一对应。随着履历的积聚，我开始认识到CloudFoundry可以或许美满地与Spinnaker平台举行共同。我必要学习大量CF的API方面的知识（实际上我是在Spring团队工作，而不是在CF团队中工作），但我学到的东西越多，这两者的连合就做得越好。
CloudFoundry与Spinnaker两者都支持将应用的多个版本举行分组以举行同一的升级或回滚、在新版本与旧版本之间实现负载均衡，而且支持开辟实例、预发布实例与生产环境的实例。它显现了Spinnaker架构的长处与机动性，而且也显现了CloudFoundry这个平台强大的本领。
InfoQ：Greg，你对于Spinnaker的哪个特性最中意？
Turnquist：当我谈到这个平台的时间，给我最多惊喜的是UI的管道编辑器，它让我可以或许举行各种随意的变动。在“CloudFoundryAfterDark”这个webcast中，我计划了一个简单的管道，此中只包罗一个步调：摆设至生产环境。在我举行形貌的同时，主持人Andrew要求我举行一些调解，让它可以或许实现摆设至预发布环境、举行冒烟测试以及摆设至生产环境。每当他话音刚落，我就已经完成了调解。随后我们开始运行管道并通过一个对用户非常友爱的界面阅读它的输出。这个平台让用户可以或许随意塑造流程，这是我们不应低估的一个强大特性。
关于Netflix的线下分享
Netflix，一个在北美日峰值占用互联网总带宽37%以上的一家网络视屏公司，每天提供环球用户1亿两千五百万小时以上的高质量影片用户体验，是怎样把全部的关键分布式底子办法寂静台搭建在AWS云端？我们会一起讨论一些微服务构架在Netflix的具体实现，以及整个工程生态体系中其他关键因素（比如公司文化）是怎样和微服务构架到达契合。点击阅读原文，立马报名。
为优质内容付费！
赞赏
人赞赏
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论