让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（自由，没有塔）做不同的工作
-
Ansible（无塔式） – configurationpipe理（服务器/应用程序configuration，批量configuration更新）
-
Rundeck – 通过访问控制，通知，作业输出等集中作业调度程序（存档旧日志，运行一些脚本等）
服务器标准是可行的。
临时/操作任务去运行。
这是我目前使用的。
-
如果您打算将它们用作开发人员或OPS团队的自助服务门户，那么我会说RBAC在Tower而不是Rundeck中更简单直观地实现。 考虑设置RBAC需要多less努力和复杂性，因为这对于支持这些产品的团队可能是至关重要的。
-
Tower中的REST API更简单，更易于parsing，而不是Rundeck。
-
在Tower中，您可以在Rundeck中查看每个Playbook任务的单个事件，所有内容都将被放置在一个控制台输出中。
-
Tower中的dynamic库存在公共云中的部署非常有用。
