Netflix 的上线工具 Spinnaker
Spinnaker 的介绍
Spinnaker 是 Netflix 开源出来的持续交付工具，目的是为研发团队提供灵活的持续交付流水线，并且支持部署到测试/生产环境。Netflix 目前通过 Spinnaker 实现每天4000次的发布。它的优势在于：
- 支持多种云平台。目前支持 AWS EC2（Netflix 的机器大部分都在亚马逊），谷歌云，Kubernetes，Azure，Openstack 等，目前正在支持甲骨文的物理机和 DC/OS。
- 自动化发布。可以集成测试脚本进行测试，并且能够管理测试，线上环境的机器，实现动态扩容，和服务的下线。
- 发布原子化。由于 Netflix 的平台已经实现微服务化，每个团队使用 Spinnaker 独立维护服务的发布，所以 Spinnaker 的设计特别适合于微服务持续交付的场景。
- 预置了软件发布的最佳实践。通过脚本实现不可变基础设施，使得发布时候能够更容易的进行回滚，和扩容。当你的团队还在为每个应用写脚本支持蓝绿发布时，Spinnaker 已经提供了从界面上进行蓝绿发布，金丝雀发布等策略的配置。
- 社区强大。Netflix，谷歌，微软等等都已经在社区贡献代码。
Spinnaker 的组成
查看 Spinnaker 的源码：https://github.com/spinnaker 可以发现，Spinnaker 的实现本身也是微服务架构，这样就意味着 Spinnaker 本身可以轻松的实现扩容和滚动升级。Spinnaker 的微服务数量也达到10个左右，目前比较核心的模块有以下几个：
Clouddriver顾名思义，是和底层 IaaS 打交道的模块，主要负责底层资源的读写，它对接了底层的云提供商： AWS，谷歌云，Kubernetes，CloudFoundry 和 Azure 等等。
以 Kubernetes 的对接为例，Clouddriver 通过 Cloud Provider Agent 实现了缓存，部署，实例，负载均衡，安全组和集群的对接，工作量还是很大的。
DeckSpinnaker 的 UI 层，使用 TypeScript + AngularJs 开发，支持扩展。
GateSpinnaker 的 API 网关层，它为其他服务提供的 API 的接入，使用 Eureka 和 OKClient 实现。
Orca任务编排引擎，目的是为 Spinnaker 提供一个流水线，将构建包从一个 Stage 升级到另一个 Stage，并且和其他服务进行协同工作。
IgorSpinnaker 的 CI 工具，Igor 提供的是统一的 CI 工具接口（Jenkins，Travis 以及 Git 仓库），并且记录 Jenkins 的认证信息。在配置 Igor 项目时，需要将 Jenkins 的登录信息配置在 yml 文件里。
使用 Spinnaker 进行持续发布
- 使用 Nebula （Netflix 打包工具）进行编译打包。
- 使用 Bake 将包打成一个镜像，或者 RPM 包。
- 并发测试这个包，集成测试，系统测试等等。
- 金丝雀发布，此阶段将包发布到集群里1%的节点，并且设置一个人工决策点。
- 1%的机器测试通过后，进行人工决策，将包发布到其他集群节点。
注：Netflix 的流程里大部分是没有人工决策点的。
集群管理：
Spinnaker 的集群管理组件能够管理以下资源：服务器组, 集群，应用，负载均衡，安全组。用这些组件来屏蔽的底层 IaaS 资源的差异。
Spinnaker 部署策略
蓝绿部署：
由于 Spinnaker 已经接管了底层的云平台资源，所以它能够实现软件部署的调度。从上图可以看到，在软件发布新版本时，我们可以为一个新集群上线新版本，将老版本的服务停掉。一旦新版本发现问题，我们可以通过 UI 上的 Rollback 按钮实现回滚。
金丝雀发布如何实现自动化？难点在于自动化评估1%节点部署的结果。Spinnaker 在发布1%集群的节点之后，ACA 会进行一系列的监控，包括用户的行为是否异常，流量的访问是否存在较大波动，最好会为这次发布计算出一个分数，这个分数就成为继续发布到10% 集群机器的数据依据，只要分数大于这个值，就能继续发布到剩余的机器。
其他功能
即时通信工具集成 – Slack
Netflix 最开始是用邮件通知构建发布的结果，后来发现邮件根本没人看，于是 Spinnaker 和 Slack 做了集成，任何发布消息都会推送到 Slack 的群聊里。好处是如果有人工的决策点需要审核，在 Slack 里可以得到及时的通知。
支持Chaos Monkey：
Chaos Monkey 之前文章有讲过，它负责在线上环境里随机的关掉某几台机器，从而进行服务高可用的测试，没有经历 Chaos Monkey 测试的服务不是好服务。
使用 Artifactory 进行软件包管理：
Netflix 是 Artifactory 的重度用户。Netflix 在部署包/镜像到生产环境时，不会重新构建，而是从测试环境找到包，复制到生产环境。这就需要包管理平台的支持，Netflix 使用 Artifactory 作为统一包管理平台，记录包的发布元数据，例如包经过了哪些测试，被部署到了哪些测试环境/生产环境。当服务需要扩容或者回滚时，根据AQL（Artifactory Query Language）进行元数据查询，找到需要扩容或回滚的包。
总结
Spinnaker 作为持续交付平台，已经被 Netflix 内部上百个团队使用，并且在生产环境里的进行了验证，同时社区也非常的活跃。
不过使用 Spinnaker 也有一些门槛，首先你需要有自动化构建，测试的流水线进行软件升级（Promotion），其次，需要让 Spinnaker 接管公司的云平台，用代码描述环境，并且已经用脚本/CMDB 实现软件在不同环境的部署，升级，回滚。如果你的公司内部有多个 Cloud Provider，并且希望实现可重复的持续交付流水线，可以考虑使用 Spinnaker 实现统一持续交付。