一切福田,不離方寸,從心而覓,感無不通。

Spinnaker 介绍 – Netflix 的持续交付平台

Spinnaker 是 Netflix 在2015年开源的一款持续交付平台,它继承了 Netflix 上一代集群和部署管理工具 Asgard:Web-based Cloud Management and Deployment的优点,同时根据公司业务以及技术的的发展抛弃了一些过时的设计:提高了持续交付系统的可复用性,提供了稳定可靠的API,提供了对基础设施和程序全局性的视图,配置、管理、运维都更简单,而且还完全兼容 Asgard,总之对于 Netflix 来说 Spinnaker 是更牛逼的持续交付平台。

在深入了解 Spinnaker 之前,先扯一扯 Netflix 的技术文化:这是一家全面拥抱云的公司,据报道数据中心完全部署在 AWS 上,是 AWS 的超级大客户。在上云后他们发现故障仍然避免不了,为了更加从容的应对这些故障,就搞了一个工具 Chaos Monkey 会随机停止生产环境中的虚拟机,通过观察系统在真实故障中的表现来确保程序的健壮性,也通过实战来验证各种高可用技术是否靠谱。接着冒出了 Chaos Gorilla,会停止一整个可用域中的所有机器;最后还有Chaos Kong,直接停掉一整个 Region,非常有挑战精神(丧心病狂)。

为了更好的观察系统在故障时的情况,还研发了全局可视化系统,代号 Flux,可以将整个系统的逻辑架构和各服务之间的流量可视化在大屏幕上,效果图如下:

他们每个月有一个活动:将一个 Region 里的机器全部关掉,看 Netflix 服务是否正常。有兴趣看视频的可以移步这里

另外,Netflix 除了云服务,还有自建CDN,即 Open Connect 项目,这个项目的边缘设备是地地道道的物理设备,并且从硬件到软件全部是自己定制的。关于 Open Connect 的详细介绍,以及使用的技术栈可以看 Netflix 的分享,还有他们如何做 CDN 监控的

主要功能

回到 Spinnaker,他主要管理 Netflix 的云服务,并不管理 OpenConnect 相关的设备和服务。Spinnaker 是基于云的 CD 平台,提供快速、可靠、稳定的软件变更服务。主要包含两类功能:集群管理(Cluster management)和部署管理(deployment management)。

1. 集群管理

集群管理主要用于管理云资源,Spinnaker 所说的“云”可以理解成 AWS,即主要是 IaaS 的资源,比如 OpenStack,Google云,微软云等,后来还支持了容器,但是管理方式还是按照管理基础设施的模式来设计的。

Spinnaker 中管理如下资源:

Server Group:最基本的逻辑资源,包括了若干使用相同配置和镜像的虚拟机,若干负载均衡(load balancer),以及安全组。
安全组规则(Security Group):就是 AWS 中的安全组,可以理解成防火墙。
负载均衡(Load Balancer):AWS 中的 ELB,也可能是安装在虚拟机中的负载均衡。

2. 部署管理

管理部署流程是 Spinnaker 的核心功能,他负责将软件包(可能是手工创建的或者 jenkins 创建的)打成一个镜像,用这个镜像生成对应的虚拟机,让服务真正运行起来:

pipeline

在 Spinnaker 中一个部署流程叫做pipeline,由若干个操作组成,每个操作又叫做一个 stage。触发一个 pipeline 方式非常灵活,可以手动触发,也可以用 jenkins、CRON 等。同时,可以配置 pipeline 向外发送一些通知信息,比如“开始”,“结束”,“失败”等。

stage

pipeline 中的一个操作,stage 之间可以有先后顺序,也可以并行。Spinnaker 中预定义了一些 stage 的类型,这些类型的 stage 往往使用频率比较高:

  • Bake:在某个 region 中制作虚拟机的镜像。Netflix 推崇不可变基础设施的理念,所以他们将软件打包进镜像的方式来部署服务。创建镜像的核心基于 Packer(Hashicorp 开源的镜像烘焙工具,Vagrant 就出自该公司 CEO 之手)。如果部署时用 docker,则打包过程就交由 docker build 完成。
  • Deploy:用 Bake 中创建的镜像部署成一台虚拟机。
  • Jenkins: 执行一个 Jenkins 的 job。
  • Manual Judgment : 暂停,等待用户的许可后再继续。
  • Pipeline : 执行另外一个 pipeline。
  • Script :执行任意的脚本。
  • Wait : 等待一段时间。

从 pipeline 的定义看,Spinnaker 和 Jenkins 有几分相似,不过两者的设计出发点的不同,stackoverflow上有相关的讨论。总结来看,jenkins 偏向 CI,产出物是软件包;Spinnaker 是 CD,将软件包分发到服务器/虚拟机上,保持软件正常运行,它的目标只是让“部署”的过程更容易更可扩展。有一个例子可以说明两者的关系:Netflix 内部有人不用 Spinnaker 的 pipeline,而只是将 Spinnaker 看为一个部署工具,直接在 jenkins 中调用它的 API 来部署服务。

逻辑架构

Spinnaker 自己是一个微服务架构,由若干组件组成,所有组件都开源在github上,整个逻辑架构如下图所示:

Deck:AngularJS 写的 WebUI。
Gate:提供 API 接口给外部程序,Deck 也是其中之一,Spinnaker 的大门。
Cloud Driver:对接各种云服务提供商,比如AWS, GCP, Azure 等。她负责所有对这些云服务的读写操作。
Orca :处理 pipeline 和任务编排,比如创建一个虚拟机,等待它创建完成,然后执行其他操作。
Rosco 基于 Packer 的镜像创建服务,她将一个 Debian 或者 RedHat 的包封装到虚拟机镜像中,这个过程有点像烘焙,所以也叫 image bake。
Front50 存储所有pipeline,应用,通知的原信息。
Igor 对接 Jenkins 的服务,比如 pipeline 中需要调用 jenkins,那么就依赖这个服务。
Echo 提供通知服务,对接各种各样的服务商:Slack, Hipchat, SMS (via Twilio) , Email。
Rush 脚本执行引擎。

管理方法

Spinnaker 看起来也是一个复杂的微服务架构,由不少服务组成,所以本身也遵循一些运维准则:

  1. 每个 Spinnaker 的服务(如 deck,gate,orca)都运行在独立的 cluster 中。
  2. 每个服务都将自己的运行指标推送到 Atlas 中,用于绘制仪表盘和报警。Atlas 是Netflix的一个内存时间序列数据库。
  3. 每个服务都将自己的日志发送到 ELK 集群中。
  4. 每个内部服务除了deck 和 gate 必须用 mutual TLS,并且证书和认证通过 Lemur 进行管理。不允许任何外部流量进入内部服务中。所有的 API 调用必须经过 gate。
  5. 每个外部服务(除了gate)都要支持 mTLS 或者 SSO。
  6. 如果某个服务有数据存储的需求,那么只能存在自己的数据库中,服务之间不共享数据存储。

为了保证兼容性,Spinnaker 在开发过程中还会准守一些准则:

  1. 保证足够的单元测试和覆盖率。
  2. 在 code review 的时候特别注意是否会破坏API兼容性。
  3. 7×24 不间断的执行集成测试。有两种集成测试,一种是一个 jenkins job,会不断调用 API 接口,确保API是按照预想的在工作,另一种是一个 Spinnaker 的 pipeline,用来执行日常任务(比如创建镜像,部署环境等)。
  4. 当发现未知的失败是,首先执行回滚操作,直到这个问题被修复。

总结

Netflix 是一个优秀的企业,有着自由的精神和先进的技术,崇尚 DevOps 文化。而 Spinnaker 是他们在践行 DevOps 文化时创造出的优秀工具,通过这些工具我们能窥见他们对微服务和敏捷开发的深刻理解,希望能够给国内的开发者一些启发和帮助。

 

from:https://www.debian.cn/archives/2577