将 Spinnaker 与作为持续交付工具的 Jenkins 2.0 进行比较

Question

众所周知，Jenkins 2.0 已经发布，它正在从持续集成 (CI) 扩展到持续交付 (CD)。所以我想问一下，Spinnaker 相比 Jenkins 2.0 有哪些竞争优势？

Answer 1

我在 Spinnaker 中的 Jenkins 集成以及 Netflix 的 Pipelines 功能方面进行了大量工作。

Spinnaker 从未打算成为端到端构建工具。 Jenkins 在管理 SCM、运行测试、构建包、拥有大量插件等方面会做得更好。

Spinnaker 试图做好的事情是获取您已发布的软件（debian 软件包、docker 映像或可部署的 JAR），并通过可高度定制的可预测软件部署周期运行它.换句话说，Spinnaker 中的每个功能都是为了让高可用性、多账户、多云工件部署变得容易。

Spinnaker 管道采用以云为中心的视图。我们的大多数管道阶段和 API 控制都与创建新服务器组和以可预测且用户友好的方式更改现有服务器组有关。如果有疑问，我们会针对这种情况进行优化。

我们对云部署的外观有更强烈的看法，在我们的 CD 管道中处理云部署任务时，我们通常会有一个点击式 UI --- 在集群 x 中找到图像，禁用此集群，调整大小一个服务器组，收缩这个集群，让这个集群占用流量，销毁这个旧集群等等。

当我们 2 多年前开始编写 Spinnaker 时，我们还没有 Jenkins 管道功能，因此我们构建了我们需要的功能。我们提出的 Jenkins 支持源于我们帮助 Netflix 的其他团队在内部构建数千个部署管道的需求。由于 Netflix 严重依赖 Jenkins 进行构建和测试，因此 Jenkins 作业和 Spinnaker 阶段之间的过渡非常无缝。

Netflix 的某些团队不使用 Spinnaker 管道功能，而是在他们的 Jenkins 作业中使用 Spinnaker API 作为部署到 AWS 的快捷方式。如果您使用 Jenkins 管道或类似的 CD 工具，Spinnaker 使您的部署阶段非常灵活。

我们也有一些团队喜欢 Spinnaker 将 Jenkins 作业分解为围绕一个应用程序的原子、可重用任务的方式。未部署到云的团队使用 Spinnaker，因为我们的管道比 Jenkins 世界更适合他们的需求。

Jenkins 管道非常整洁。我认为 Spinnaker 永远不会完全取代 Jenkins 及其所做的数百万件事。我们的目标是让“部署到云”步骤更简单、更可扩展。选择使用其中一个，一起使用还是完全不使用，取决于您。

Answer 2

您可能出于以下几个原因选择 Spinnaker 而不是 Jenkins (2.0) Pipeline 作为 CD 工具：

1. Spinnaker 包含一个 Web UI，可以实际配置资源，并在多个云环境中执行此操作。因此，要创建虚拟机、负载平衡器、集群等基本资源，您可以通过与交付工具相同的 UI 来执行此操作。
2. 如果您的架构与 Netflix 的架构相似，Netflix 会将其用作他们的整个云管理平台，因此几乎不需要庞大的工具来支持您的交付和基础架构管理。

另一方面，选择 Jenkins Pipeline 而不是 Spinnaker 的原因有很多

1. Spinnaker 仍需要构建工具，因此您可能仍需要维护 Jenkins。因此，如果 Jenkins Pipeline 成为您的 CD 工具，它已经可以在本地执行您的特定于执行程序的任务。
2. Spinnaker 没有细粒度的访问控制（并且只是最近才添加了任何类型的身份验证），而 Jenkins 在 Pipeline 中有许多插件和本机配置来提供资源级访问控制。
3. 一切都由一个 groovy 脚本驱动，因此它是真正的配置即代码。它支持简单的流程/逻辑/控制，而这在其他 CD 工具中是不可能的（或至少是简单的）。
4. 多分支管道支持，轻松创建/删除/更改分支
5. 已经对 Jenkins 提供了广泛的插件支持。例如，我们使用 AWS ECS Plugin 来允许我们的管道使用动态 docker 节点。
6. 轻松共享/协作处理流水线的代码。您肯定会拥有想要跨多个管道使用的可重用功能，Jenkins 使用 Remote Loader Plugin 等工具使这变得容易
7. 大型社区支持

我们最终选择了 Jenkins 2.0 Pipeline 作为我们的 CD 工具，而不是 Spinnaker 和其他几个工具。

Answer 3

我们使用 Maven 将整个代码库与配置、属性（即 GitHub 中的所有版本）打包在一起，并从中创建一个 RPM。随着这个流程的结束 - 我们触发 AWS 或任何其他云中的 Spinnaker 管道来启动 CD 部分。

Spinnaker 在这个给定的 CD 范围内非常独特。

1. 代码提升：我们将提升的相同 RPM 确保我们使我们的底层代码/环境不可变。

2. 我们可以从 Spinnaker 控制台本身控制实例的大小调整

3. 一键回滚。

4. 所有现代部署概念，如 Blue-green / Red-Black 、 Canary 、 highlander 等，在这里都是 OOB。

5. 管道日志提供了一个非常有洞察力的视图，无论是高级别还是低级别

6. 多区域部署（DR 战略）

如果有人需要帮助（免费帮助！）在 RHEL 中安装 Spinnaker，您可以告诉我。

但我必须说，我们仅将 Spinnaker 用于以云为中心的部署。