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

Question

众所周知,Jenkins 2.0已经发布,它不仅仅是持续集成(CI),还包括持续交付(CD).所以我想问一下,与Jenkins 2.0相比,Spinnaker的竞争优势是什么？

Answer 1

我在Spinnaker的Jenkins集成和Netflix的Pipelines功能方面进行了广泛的工作.

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

Spinnaker试图做得好的事情是使用您已发布的软件(debian软件包,docker镜像或可部署的JAR)并通过可高度自定义的可预测软件部署周期运行它.换句话说,Spinnaker中的每个功能都可以轻松实现高可用性,多帐户,多云工件部署.

三角帆管道采用以云为中心的视图.我们的大多数管道阶段和API控件都关注创建新服务器组和以可预测和用户友好的方式更改现有服务器组.如有疑问,我们会优化这种情况.

我们对云部署的外观有更强烈的意见,在处理我们的CD管道中的云部署任务时,我们通常会有点击式用户界面 - 在集群x中查找映像,禁用此集群,调整服务器组的大小,缩小此群集,使此群集占用流量,销毁此旧群集等.

当我们2年前开始编写Spinnaker时,我们无法使用Jenkins管道功能,因此我们构建了所需的功能.我们提出的Jenkins支持源于我们的需求,帮助Netflix的其他团队在内部构建数千个部署管道.由于Netflix大量依赖Jenkins进行构建和测试,因此Jenkins工作和Spinnaker阶段之间的转换非常顺畅.

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

我们也有团队喜欢Spinnaker将Jenkins工作分解为一个应用程序的原子,可重用任务的方式.未部署到云的团队使用Spinnaker,因为我们的管道比他们能够找到的Jenkins世界更能满足他们的需求.

詹金斯的管道非常整洁.我不认为Spinnaker会完全取代Jenkins及其所做的百万件事.我们的目标是让"部署到云"步骤更简单,更具可扩展性.选择使用其中一个,一起使用或根本不使用,取决于您.

Answer 2

有几个原因可以选择Spinnaker而不是Jenkins(2.0)Pipeline作为CD工具:

1. Spinnaker包含一个可以实际配置资源的Web UI,并且可以在多个云环境中实现.因此,要创建VM,负载均衡器,集群等基本资源,您可以使用与交付工具相同的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插件等工具轻松实现这一功能
7. 大型社区支持

我们最终选择Jenkins 2.0 Pipeline作为我们的Spinnaker和其他几个CD工具.