PROSAGA码农传奇-Teambition-使Ansible和Rundeck一起工作是个好主意，还是使用其中之一就足够了？

TL; DR-考虑到您的Jenkins CI / CD环境，我建议仅使用Ansible。

您已经发现Ansible和Rundeck之间存在很大的交叉，因此最好集中精力于每种产品的重点，样式和用途。

焦点

我相信Rundeck的重点是使系统管理员能够构建一个（基于Web的）自助服务门户，其他系统管理员以及（可能）较少“技术” / sysadmin人员都可以访问该门户。Rundeck的网站说：“ 将您的操作程序转变为自助服务。安全地给予其他人所需的控制权和可见性。 ” Rundeck还感觉到它对世界的看法更加“集中”：您将工作加载到数据库中，并且工作就在这里。

对我而言，Ansible是针对开发人员的-因此以高度可重复的方式构建和自动化（自建）应用程序的部署。我认为，Ansible会更侧重于构建自己的产品的软件开发公司：Ansible的“剧本”是文本文件，因此通常存储在源代码管理中，并且通常与剧本将部署的应用程序一起存储。

创造就业机会

使用Rundeck，您通常可以通过Web UI创建作业。

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

操作/任务/工作方式

默认情况下，Rundeck势在必行-您编写（通过SSH）执行的脚本。

Ansible既是命令性的（即执行bash语句），又是声明性的，因此在某些情况下，例如，启动Apache可以使用该service任务来确保其正在运行。这更接近其他配置管理工具，例如Puppet和Chef。

复杂的工作/脚本

Rundeck可以通过在Job的工作流程中定义一个步骤来运行另一个作业，但是根据经验，这感觉像是附加的功能，而不是严肃的顶级功能。

Ansible旨在创建复杂的操作；running / include / etc是顶级功能。

运行方式

Rundeck是服务器应用程序。如果要从其他地方（例如CI）运行作业，则需要调出cli或进行API调用。

直Ansible是命令行。

普罗维索

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

你的问题：

补充工具？

我可以设想同时使用这两种方式的SaaS商店：一个人可以使用Ansible执行所有部署操作，然后使用Rundeck执行一次性的临时任务。

但是，尽管可以设想，但我不建议您以此作为起点。我，我将从Ansible开始，看看我能走多远。如果我发现我真的非常需要一次性运行，那么以后我只会在Rundeck分层。

CI / CD

Ansible：您的环境听起来更像是您要部署自己的应用程序的软件仓库。它可能应该是可重复的（尤其是在进行持续交付时），因此您将希望在源代码管理中使用部署脚本。您将需要简单性，而Ansible是“仅文本文件”。我希望您也希望您的开发人员能够在他们的机器上运行东西（对吗？），Ansible是分散式的。

一起使用（用于CI / CD）

从Ansible呼叫Rundeck，否。当然可以，但我正在努力提出充分的理由。至少，不是非常专业化的针对特定应用程序或框架的原因。

从Rundeck打电话给Ansible，是的。我可以设想有人首先在Ansible中构建一些可重复的即席命令。然后，我可以看到在没有命令行的情况下能够调用它的需求不大（例如：非技术用户）。但是，这又再次针对您的环境。