49

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

4

3 回答 3

85

我在 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 及其所做的数百万件事。我们的目标是让“部署到云”步骤更简单、更可扩展。选择使用其中一个，一起使用还是完全不使用，取决于您。

于 2016-07-16T03:32:14.783 回答
30

您可能出于以下几个原因选择 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 插件来允许我们的管道使用动态 docker 节点。
  6. 轻松共享/协作处理流水线的代码。您肯定会拥有想要跨多个管道使用的可重用功能，Jenkins 使用Remote Loader Plugin等工具使这一切变得容易
  7. 大型社区支持

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

于 2016-06-22T14:57:57.610 回答
1

我们使用 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 用于以云为中心的部署。

于 2018-01-17T08:55:49.347 回答