让Ansible和Rundeck一起工作还是使用其中一个就足够了?

最近我在看Ansible,并希望在项目中使用它。 还有另外一个工具,Rundeck可以用来做各种操作工作。 我没有任何工具的经验,这是我目前对他们的理解:

类似的点

  • 这两种工具都是无代理的,并使用SSH在远程服务器上执行命令

  • Rundeck的主要概念是Node,和Ansible的库存一样,关键的想法是定义/pipe理/分组目标服务器

  • Rundeck可以在选定的节点上执行ad-hoc命令,Ansible也可以非常方便地执行此操作。
  • Rundeck可以定义工作stream程并在选定的节点上执行,这可以通过编写Playbook来完成
  • Rundeck可以和Jenkins这样的CI工具集成在一起进行部署工作,我们也可以定义一个Jenkins的工作来运行ansible-playbook来完成部署工作

不同点

  • Rundeck有Job的概念,Ansible没有

  • Rundeck有Job Scheduler,Ansible只能用Jenkins或Cron任务等其他工具来实现

  • Rundeck免费获得dedault的Web UI,但是您必须为Ansible Tower付费

看起来Ansible和Rundeck都可以用来做configuration/pipe理/部署工作,也许用不同的方式。 所以我的问题是:

  • 这两个互补的工具,或者他们是为不同的目的而devise的? 如果他们是互补的工具,为什么Ansibl只能和厨师/木偶/平板工具比较,而不能和Rundeck? 如果他们不是为什么他们有这么多类似的function?
  • 我们已经在使用Jenkins for CI来构build一个Continuous-Deliverypipe道,那么使用哪个工具(Ansible / Rundeck)来执行部署更好?
  • 如果可以一起使用,最好的做法是什么?

任何build议和经验分享,不胜感激。 提前致谢。

最好的祝福。

TL; DR – 考虑到Jenkins的CI / CD环境,我推荐使用Ansible。

你已经发现Ansible和Rundeck之间有相当大的交叉,所以最好把注意力集中在每个产品关注的地方,它的风格和用途。

焦点

我相信,Rundeck的重点是让系统pipe理员能够build立一个(基于networking的)自助服务门户,其他系统pipe理员以及可能不太“技术”/系统pipe理员都可以访问这个门户。 Rundeck的网站上说:“ 把你的操作程序变成自助服务工作,安全地给他人提供他们需要的控制和知名度。 ” Rundeck也觉得它对这个世界有一个更“集中”的看法:把工作加载到数据库中,这就是他们的生活。

对我来说,Ansible适用于devops,因此构build和自动部署(自build)应用程序的方式使得它们具有高度可重复性。 我认为Ansible更专注于开发自己产品的软件开发公司:Ansible的“剧本”是文本文件,通常存储在源代码控制中,通常与剧本将部署的应用程序一起存储。

创造就业的重点

通过使用Rundeck,您通常可以通过Web UI创build作业。

通过Ansible,您可以通过文本编辑器在文件中创build任务/剧本。

操作/任务/作业风格

缺省情况下,Rundeck是必不可less的 – 你编写脚本(通过SSH)。

Ansible既是命令(即执行bash语句),也是声明式的,所以在某些情况下,比如说启动Apache,你可以使用service任务来确保它正在运行。 这与Puppet和Chef等其他configurationpipe理工具更为接近。

复杂的作业/脚本

Rundeck有能力通过在Job的工作stream程中定义一个步骤来运行另一个工作,但是从经验来看,这感觉就像是一个附加的东西,而不是一个严重的顶级特性。

Ansible旨在创build复杂的操作; 运行/包括/等是顶级function。

它如何运行

Rundeck是一个服务器应用程序。 如果你想从其他地方(比如CI)运行作业,你需要调用cli或者调用API。

直接Ansible是命令行。

条件

由于Rundeck Ansible的交叉和整体的灵活性,你可以在每个上面实现上述所有的function。 您可以通过将它们导出到YAML或XML并将其检入源代码pipe理来实现Rundeck作业的版本控制。 您可以使用Tower在Ansible中获得Web UI。 等等等等

你的问题:

补充工具?

我可以设想一个SaaS商店使用两种方式:可以使用Ansible执行所有部署操作,然后使用Rundeck执行一次性即席作业。

不过,虽然我可以设想,但我不会build议这个出发点。 我,我会从Ansible开始,看看我能得到多less。 如果我发现我真的需要一次性运行,那么我以后只能在Rundeck中进行分层。

CI / CD

Ansible:您的环境听起来更像是一个软件公司,您正在部署自己的应用程序。 它应该是可重复的(特别是当你要持续交付),所以你会希望你的部署脚本在源代码控制。 你会想要简单,Ansible是“只是文本文件”。 我希望你也希望你的开发者能够在他们的机器上运行(右?),Ansible是分散的。

一起使用(用于CI / CD)

从Ansible调用Rundeck,没有。 当然,这是可能的,但我正在努力想出很好的理由。 至less,不是非常专业化的特定应用程序或框架原因。

从Rundeck调用Ansible,是的。 我可以设想一个人首先在Ansible中构build一些可重复的adhoc命令。 然后,我可以看到有一点需求可以在没有命令行的情况下调用(比如非技术用户)。 但是,这又一次变得特定于你的环境。

这完全取决于您的要求。 我使用rundeck来执行远程脚本和应用程序部署。 我已经与Foreman集成,涵盖了configuration和configurationpipe理。

如果你有预算限制,再看看,Rundeck岩石。 虽然你可能会错过Ansible中的一些function。 另外,谷歌集团在支持的情况下非常活跃。

如果你把预算投资在一座塔上,你可能不需要别的东西。

我的观点 – rundeck和ansible(自由,没有塔)做不同的工作

  1. Ansible(无塔式) – configurationpipe理(服务器/应用程序configuration,批量configuration更新)

  2. Rundeck – 通过访问控制,通知,作业输出等集中作业调度程序(存档旧日志,运行一些脚本等)

服务器标准是可行的。

临时/操作任务去运行。

这是我目前使用的。

  1. 如果您打算将它们用作开发人员或OPS团队的自助服务门户,那么我会说RBAC在Tower而不是Rundeck中更简单直观地实现。 考虑设置RBAC需要多less努力和复杂性,因为这对于支持这些产品的团队可能是至关重要的。

  2. Tower中的REST API更简单,更易于parsing,而不是Rundeck。

  3. 在Tower中,您可以在Rundeck中查看每个Playbook任务的单个事件,所有内容都将被放置在一个控制台输出中。

  4. Tower中的dynamic库存在公共云中的部署非常有用。