将一个artifact交付到生产环境需要很多工具。 用于构建和测试的工具，用于创建可部署的artifact（如容器镜像）的工具，用于身份验证和授权的工具，用于维护基础设施的工具等等。 将这些工具无缝集成到工作流程中可以改变工程文化，但是自己做可能是一项艰巨的任务。
随着组织的成熟，工具的数量和管理它们的人员的数量往往会增加，这通常会导致令人困惑的复杂性和碎片化。 定制的持续交付（CD）流程可能在较小的规模上有效，但是维护和理解它变得越来越具有挑战性。 新工程师可能需要很长时间才能发现并整理部署即使是最简单的更改所需的所有工具。
Spinnaker 的创建就是为了解决这个问题。 它是一个通用且可扩展的工具，为用户提供构建块以创建量身定制的持续交付管道。 您无需花费时间和承担增加的风险来发明自己的方法，而可以使用一种已经受到 Netflix 和 Google 等主要公司信任和开发的解决方案来处理数千个应用程序的交付。
Spinnaker 的起源
Netflix 过去有一个零散的持续交付故事。 每个组织的交付系统都是专门为该组织构建的，因此其他人通常无法从中受益。 团队认为自己是独一无二的，并将 Jenkins 作业与 Asgard 结合在一起。 所有这些重复的努力不仅浪费，而且难以使团队精通并及时了解最新的交付最佳实践。
2014 年，团队一致认为，像 Jenkins 这样的通用持续集成（CI）工具无法提供合适的基础来构建具有他们所需安全性和灵活性的持续交付平台。 为此，诞生了一个新工具。 Netflix 的交付工程团队与 Google 合作构建了 Spinnaker，这是一个多云持续交付和基础设施管理工具，该工具将集中管理并且足够灵活，可以使团队自定义其自己的交付，但又足够标准化，可以为每个人带来最佳实践和安全性。 Spinnaker 将我们数十年来编写和交付软件的经验编纂成每个人都可以使用的东西，而无需经历同样的成长之痛。
自从 Spinnaker 在开源社区中被广泛采用以来，维护人员一直在不断添加新功能和集成，以使 Spinnaker 在 Netflix、Google、Airbnb、Pinterest 和 Snap 等公司中更加有用和实用。
Spinnaker 的实践
使用 Spinnaker，您可以 构建由阶段组成的灵活管道，以按照您需要的方式交付软件。 您可以有一个“部署”阶段，该阶段编排新基础设施的创建和清理，并使用蓝/绿策略来实现零停机时间。 如果您想更直接地控制发布过程，可以添加一个“手动判断”阶段，该阶段会等待外部确认。 这些阶段可以组合成能够表示复杂且自定义的交付工作流程的管道。
管道的灵活性，加上一套全面的内置阶段，使 Spinnaker 能够吸引各个团队。 这方面一个明显的例子是我们的 金丝雀 阶段，它评估一组指标以确定部署是否健康。 在 Spinnaker 之前，许多团队无法在其部署管道中使用金丝雀，因为它与旧的金丝雀系统集成过于麻烦。 这个“内置电池”的金丝雀阶段是将许多团队带到 Spinnaker 的胡萝卜。
如果您需要自定义行为，阶段还提供一个扩展点来封装特定于您的组织或团队的逻辑。 这些扩展可以是开源的或闭源的。 例如，您可以添加自定义功能来更新 Jira 工单的状态、刷新缓存或拍摄数据库快照。
Spinnaker 自定义
作为一个通用工具，Spinnaker 可以开箱即用地做很多事情； 但是，当您自定义它时，它会真正发光。 当您向组织中的其他工具添加集成或分享最佳实践时，可以更轻松地帮助团队安全可靠地部署和运营软件。
我们为 Spinnaker 添加了各种各样的自定义集成，使其具有粘性。 以下内容可能会激发您如何自定义 Spinnaker 以适应您的组织的想法。
提高开发人员效率
我们所做的一个简单的 UI 自定义是在每个实例旁边都有一个图标，允许您将 SSH 命令复制到该实例。 我们通过使用 Netflix 专用组件覆盖 UI 中的“实例详细信息”面板来实现此目的，该组件从配置文件（基本 SSH 命令）中获取一些信息，将实例 ID 插入该命令中，并使其作为实例 ID 旁边的一个小剪贴板按钮提供。
提高安全性
在过去的五年中，我们与安全团队紧密合作，将最佳实践融入 Spinnaker。 其中一个例子是我们如何为每个应用程序自动创建身份和访问管理（IAM）角色，并使用这些角色来限制谁可以在 AWS 中做什么，从而使每个团队都拥有完成工作所需的权限。
我们使用以下两个部分来实现此目的： （1）我们在 Clouddriver（执行云操作的微服务）中添加了一个自定义类，该类与 （2）由我们的安全团队维护的 Lambda 函数通信。
对于每个云突变操作，我们都会与 AWS 确认是否存在具有该应用程序名称的 IAM 角色； 如果不存在，我们会与安全服务确认是否应创建一个。 如果需要创建角色，我们会向安全服务提供它需要的信息，以确保 IAM 角色已成功创建。
由于这种设置，我们可以轻松控制每个实例启动的 IAM 配置文件，同时将 IAM 功能的核心留给安全团队。 这为他们提供了灵活性来更改他们的实施、添加功能或执行额外的审计，而无需更改 Spinnaker。
我们经常使用 Spinnaker 钩子和生成的合作伙伴团队服务调用模式。 它有助于将 Spinnaker 的关注点（即作为交付平台）与合作伙伴团队管理的关注点（例如安全性）分开。 这种分离还支持合作伙伴团队独立创新的能力，从而为我们的用户带来更好、更安全的交付体验。
提高可追溯性和审计
自定义集成的最后一个示例是将 Spinnaker 事件流 发送到另一个服务。 Spinnaker 执行许多突变操作，通常您可能需要记录这些事件以用于审计或合规性目的。 我们将所有事件发送到我们的大数据存储，以便公司内的其他团队可以使用这些数据。
我们还管理一个符合 PCI 的环境。 以前，我们有一个与 Spinnaker 实例位于同一位置，该实例在此隔离环境中运行以保持合规性。 今年，我们在 Spinnaker 中启用了 Fiat 授权微服务，对其进行了强化，并通过维护单个 Spinnaker 来统一所有属性。
结论
正确地进行持续交付非常困难。 Spinnaker 是一个经过强化且维护良好的工具（在过去一个月中大约有 460 个合并的拉取请求），它具有许多与流行服务的现有集成，同时还支持自定义集成以提高灵活性。 Netflix、Google、Amazon、Nike、Cisco 和 Salesforce 等大型公司都在积极为 Spinnaker 做出贡献。 采用 Spinnaker 使您可以集中持续交付并获得最佳实践。 为什么不加入 Spinnaker 社区，而不是重新发明轮子呢？
如果您对此主题感兴趣，请于 11 月 15 日至 17 日在圣地亚哥的 Spinnaker 峰会上与用户、维护人员和交付领域的其他人员交谈。
2 条评论