TL;DR -考虑到您的Jenkins CI/CD环境，我建议仅使用Ansible。
你已经发现Ansible和Rundeck之间有相当大的交叉，所以最好集中在每个产品的重点，它的风格和使用。

专注

我相信Rundeck的重点是让系统管理员能够建立一个（基于网络的）自助门户，其他系统管理员以及可能不太“技术”的人/系统管理员都可以访问。Rundeck的网站上写着“* 把你的操作程序变成自助作业。安全地给予其他人他们需要的控制和可见性。*"。Rundeck还感觉它对世界有一个更”集中“的看法：你把作业加载到数据库中，它们就在那里。
对我来说，Ansible是面向devops的--以一种高度可重复的方式构建和自动化部署（自构建）应用程序。我认为Ansible更专注于构建自己产品的软件开发公司：Ansible的“剧本”是文本文件，因此通常存储在源代码控制中，通常与剧本将要部署的应用程序放在一起。

注重创造就业机会

使用Rundeck，您通常可以通过Web UI创建作业。
使用Ansible，您可以通过文本编辑器在文件中创建任务/剧本。

工序/任务/作业类型

默认情况下，Rundeck是命令式的--您编写要执行的脚本（通过SSH）。
Ansible既是命令式的（例如执行bash语句），也是声明式的，所以在某些情况下，比如启动Apache时，可以使用service任务来确保它正在运行，这更接近于其他配置管理工具，如Puppet和Chef。

复杂作业/脚本

Rundeck能够通过定义作业工作流中的一个步骤来运行另一个作业，但从经验来看，这感觉像是一个附加的附加功能，而不是一个严重的顶级功能。
Ansible旨在创建复杂的操作;运行/包括/等是顶级特征。

它如何运行

Rundeck是一个服务器应用程序。如果你想从其他地方（如CI）运行作业，你需要调用cli或进行API调用。
直Ansible是命令行。

但书

由于Rundeck * 和 * Ansible的交叉和整体灵活性，您可以在每个版本中实现上述所有功能。您可以通过将Rundeck作业导出为YAML或XML并将其签入源代码控制来实现其版本控制。您可以使用Tower. etc. etc.等在Ansible中获得Web UI。
您的问题：

• 辅助工具 *

我可以设想一个SaaS商店同时使用：可以使用Ansible来执行所有部署动作，然后使用Rundeck来执行一次性的特别作业。
然而，虽然我可以想象它，但我不建议把它作为一个起点。我，我会从Ansible开始，看看我能走多远。只有当我发现我真的，真的需要运行一次时，我才会在Rundeck中分层。

• 刑事调查/民事调查 *

Ansible：你的环境听起来更像是一个你在部署自己的应用程序的软件公司。它可能应该是可重复的（特别是当你要持续交付的时候），所以你会希望你的部署脚本在源代码控制中。你会希望简单，Ansible是“仅仅是文本文件”。我希望你也希望你的开发者能够在他们的机器上运行东西（对吗？），Ansible是分散的。

• 一起使用（用于CI/CD）*

从Ansible调用Rundeck，不行。当然，这是可能的，但我很难想出好的理由。至少，不是非常专业的特定应用程序或框架的理由。
从Rundeck调用Ansible，是的。我可以想象有人首先在Ansible中构建一些可重复的临时命令。然后我可以看到有一点需求，即能够在没有命令行的情况下调用它（例如：非技术用户）。但是，同样，这是特定于您的环境的。

在问这个问题的时候，作者正确地指出Ansible只提供了一个收费的UI。
用户界面现已开源：AWX

我的point-rundeck和ansible（免费，没有塔）做不同种类的工作

1. Ansible（无塔式机）-配置管理（服务器/应用程序配置、批量配置更新）
2. Rundeck -具有访问控制、通知、作业输出等功能的集中式作业调度程序（存档旧日志、运行一些脚本等）

它完全基于你的需求。我使用rundeck来远程脚本执行和应用部署。我已经将它与Foreman集成来覆盖供应和配置管理。
如果你有预算限制，不要再看了，Rundeck很棒。不过你可能会错过Ansible的一些功能。另外，谷歌集团在支持方面也非常活跃。
如果你有预算，投资在ansible塔，你可能不需要其他任何东西。

服务器标准可行。
临时/操作任务转到rundeck。
这是我目前使用的。

1.如果您打算将它们用作开发人员或OPS团队的自助服务门户，那么我会说RBAC在Tower中比在Rundeck中更简单、直观、更清晰地实现。考虑设置RBAC需要多少工作和复杂性，因为它对支持此产品的团队至关重要。

1. Tower中的REST API比Rundeck中的更简单、更容易解析。
   1.在Tower中，您可以查看每个剧本任务的单个事件，而在Rundeck中，所有事件都在一个控制台输出中抛出。
2. Tower中的动态清单对于公共云中的部署非常有用。

我同时使用这两种工具，因为在我看来，它们并没有太多的重叠。Ansible本身可以被认为是一种更简单的脚本编写方式，因为它提供了完成复杂任务的模块，有些甚至是有状态的。其中，Rundeck作为自助服务门户非常完美。Ansible本身缺乏的一些用例
1.自动事件响应
1.由非技术人员执行的复杂操作任务（为某些潜在客户创建演示示例）
1.在执行所需任务时限制对环境的访问（在没有访问权限的数据库系统上运行特定sql）
1.管理cronjob的中央系统（您可以重用cronjob和跟踪日志，并与通知系统集成）
在Ansible中这样做是重新发明轮子，将花费大量时间。就我个人而言，我将它们一起使用，但并不总是这样，因为有时候并不需要这样做。所以这是一个何时将它们一起使用的问题，肯定不是其中任何一个都足够。