让 Ansible 和 Rundeck 一起工作是个好主意，还是使用其中一个就足够了？
Is it a good idea to make Ansible and Rundeck work together, or using either one is enough?
最近在看Ansible，想在项目中使用。还有另一个工具 Rundeck 可用于执行各种操作工作。我对这两种工具都没有经验，这是我目前对它们的理解：
相似点数
这两个工具都是无代理的，使用 SSH 在远程服务器上执行命令
Rundeck的主要概念是Node，和Ansible的inventory一样，关键思想是define/manage/group目标服务器
- Rundeck 可以在选定的节点上执行临时命令，Ansible 也可以非常方便地执行此操作。
- Rundeck 可以定义工作流并在选定的节点上执行，这可以通过编写 playbook 使用 Ansible 来完成
- Rundeck 可以与 Jenkins 等 CI 工具集成来做部署工作，我们也可以定义一个 Jenkins 作业到 运行 ansible-playbook 来做部署工作
不同点
Rundeck 有 Job 的概念，而 Ansible 没有
Rundeck 有 Job Scheduler，Ansible 只能通过 Jenkins 或 Cron 任务等其他工具实现此功能
Rundeck 默认免费提供 Web UI，但 Ansible Tower 需要付费
似乎 Ansible 和 Rundeck 都可以用来做 configuration/management/deployment 工作，也许是以不同的方式。所以我的问题是：
- 这两个工具是互补的还是为不同的目的而设计的？如果它们是互补工具，为什么 Ansibl 只与 Chef/Puppet/Slat 之类的工具进行比较，而不是与 Rundeck 进行比较？如果不是为什么他们有这么多相似的功能？
- 我们已经在 CI 中使用 Jenkins 来构建持续交付管道，哪个工具 (Ansible/Rundeck) 更适合用于部署？
- 如果它们可以一起使用，最佳做法是什么？
非常感谢任何建议和经验分享。
这完全取决于您的要求。
我使用 rundeck 进行远程脚本执行和应用程序部署。我已将其与 Foreman 集成以涵盖供应和配置管理。
如果您的预算有限，别再犹豫了，Rundeck 很棒。不过，您可能会错过 Ansible 中的一些功能。此外，Google 小组在支持方面非常活跃。
如果您有预算投资 ansible tower，您可能不需要其他任何东西。
TL;DR - 考虑到你的 Jenkins 环境 CI/CD 我建议只使用 Ansible。
您已经发现 Ansible 和 Rundeck 之间存在相当大的交叉，因此最好专注于每个产品的重点、风格和用途。
专注
我相信 Rundeck 的重点是使系统管理员能够构建一个（基于 Web 的）自助服务门户，其他系统管理员和可能更少的 "technical"/sysadmin 人员都可以访问该门户。 Rundeck 的网站说：“将您的操作程序转变为自助服务工作。安全地为他人提供他们所需的控制和可见性。”。 Rundeck 也感觉它对世界有更多 'centralised' 的看法：你将工作加载到数据库中，这就是他们所在的地方。
对我来说，Ansible 适用于 devops - 因此以高度可重复的方式构建和自动化部署（自建）应用程序。我认为 Ansible 更侧重于构建自己产品的软件开发公司：Ansible 'playbooks' 是文本文件，因此通常存储在源代码管理中并且通常与剧本将部署的应用程序一起存储。
创造就业重点
使用 Rundeck，您通常可以通过网络创建工作 UI。
使用 Ansible，您可以通过文本编辑器在文件中创建 tasks/playbooks。
Operation/Task/Job风格
默认情况下，Rundeck 是命令式的 - 您编写的脚本将被执行（通过 SSH）。
Ansible 既是命令式的（即执行 bash 语句）也是声明式的，所以在某些情况下，比如说，启动 Apache 你可以使用 service 任务来确保它是 运行宁。这更接近于 Puppet 和 Chef 等其他配置管理工具。
复杂作业/脚本
Rundeck 可以通过在作业的工作流程中定义一个步骤来 运行 另一项作业，但从经验来看，这感觉像是附加功能，而不是重要的顶级功能。
Ansible 旨在创建复杂的操作； running/including/etc 是顶级功能。
如何 运行s
Rundeck 是一个服务器应用程序。如果你想从其他地方 运行 工作（比如 CI），你需要调用 cli 或进行 API 调用。
Straight Ansible 是命令行。
附带条件
由于 Rundeck 和 Ansible 的交叉和整体灵活性，您可以在每个中实现上述所有目标。您可以通过将 Rundeck 作业导出到 YAML 或 XML 并将它们签入源代码管理来实现对 Rundeck 作业的版本控制。您可以使用 Tower 在 Ansible 中获得一个网络 UI。等等等等等等
您的问题：
辅助工具？
我可以设想 SaaS 商店同时使用这两种方法：可以使用 Ansible 执行所有部署操作，然后使用 Rundeck 执行一次性的临时作业。
但是，虽然我可以设想它，但我不建议将其作为起点。我，我会从 Ansible 开始，看看我能走多远。如果我发现我真的 真的 需要 运行 一次性，我只会在 Rundeck 中分层。
CI/CD
Ansible：您的环境听起来更像是一个软件屋，您可以在其中部署自己的应用程序。它可能应该是可重复的（尤其是当你要持续交付时）所以你会希望你的部署脚本在源代码控制中。你会想要简单，而 Ansible 是 "just text files"。我希望您也希望您的开发人员能够 运行 在他们的机器上进行操作（对吗？），Ansible 是去中心化的。
一起使用(for CI/CD)
从 Ansible 调用 Rundeck，没有。当然，这是可能的，但我正在努力想出充分的理由。至少，不是非常专业的特定于特定应用程序或框架的原因。
从 Rundeck 调用 Ansible，是的。我可以设想有人首先在 Ansible 中构建一些可重复的临时命令。然后我可以看到有一些需求能够在没有命令行的情况下调用它（比如：非技术用户）。但是，这又是针对您的环境的。
服务器标准变得可行。
Adhoc/operation 任务进入跑道。
这是我目前使用的
如果您打算将它们用作开发人员或 OPS 团队的自助服务门户
那么我会说 RBAC 在 Tower 中而不是在 Rundeck 中实现更简单，直观上更清晰。考虑设置 RBAC 需要付出多少努力和复杂性，因为它对于支持此产品的团队至关重要。
REST API 在 Tower 中比在 Rundeck 中更简单、更容易解析。
在 Tower 中，您可以看到每个 playbook 任务的单独事件，而在 Rundeck 中，所有内容都在一个控制台输出中抛出。
Tower 中的动态清单对于 public 云中的部署非常有用。
我的观点 - 运行deck 和 ansible（免费，没有塔）做不同类型的工作
Ansible（无塔）- 配置管理（服务器/应用程序提供，批量配置更新）
Rundeck - 具有访问控制、通知、作业输出等功能的集中式作业调度程序（存档旧日志、运行 一些脚本等）
在提出这个问题时，作者正确地指出 Ansible 只提供了一个 UI 收费。
UI现已开源：AWX
最近在看Ansible，想在项目中使用。还有另一个工具 Rundeck 可用于执行各种操作工作。我对这两种工具都没有经验，这是我目前对它们的理解：
相似点数
这两个工具都是无代理的，使用 SSH 在远程服务器上执行命令
Rundeck的主要概念是Node，和Ansible的inventory一样，关键思想是define/manage/group目标服务器
- Rundeck 可以在选定的节点上执行临时命令，Ansible 也可以非常方便地执行此操作。
- Rundeck 可以定义工作流并在选定的节点上执行，这可以通过编写 playbook 使用 Ansible 来完成
- Rundeck 可以与 Jenkins 等 CI 工具集成来做部署工作，我们也可以定义一个 Jenkins 作业到 运行 ansible-playbook 来做部署工作
不同点
Rundeck 有 Job 的概念，而 Ansible 没有
Rundeck 有 Job Scheduler，Ansible 只能通过 Jenkins 或 Cron 任务等其他工具实现此功能
Rundeck 默认免费提供 Web UI，但 Ansible Tower 需要付费
似乎 Ansible 和 Rundeck 都可以用来做 configuration/management/deployment 工作，也许是以不同的方式。所以我的问题是：
- 这两个工具是互补的还是为不同的目的而设计的？如果它们是互补工具，为什么 Ansibl 只与 Chef/Puppet/Slat 之类的工具进行比较，而不是与 Rundeck 进行比较？如果不是为什么他们有这么多相似的功能？
- 我们已经在 CI 中使用 Jenkins 来构建持续交付管道，哪个工具 (Ansible/Rundeck) 更适合用于部署？
- 如果它们可以一起使用，最佳做法是什么？
非常感谢任何建议和经验分享。
这完全取决于您的要求。 我使用 rundeck 进行远程脚本执行和应用程序部署。我已将其与 Foreman 集成以涵盖供应和配置管理。
如果您的预算有限，别再犹豫了，Rundeck 很棒。不过，您可能会错过 Ansible 中的一些功能。此外，Google 小组在支持方面非常活跃。
如果您有预算投资 ansible tower，您可能不需要其他任何东西。
TL;DR - 考虑到你的 Jenkins 环境 CI/CD 我建议只使用 Ansible。
您已经发现 Ansible 和 Rundeck 之间存在相当大的交叉，因此最好专注于每个产品的重点、风格和用途。
专注
我相信 Rundeck 的重点是使系统管理员能够构建一个（基于 Web 的）自助服务门户，其他系统管理员和可能更少的 "technical"/sysadmin 人员都可以访问该门户。 Rundeck 的网站说：“将您的操作程序转变为自助服务工作。安全地为他人提供他们所需的控制和可见性。”。 Rundeck 也感觉它对世界有更多 'centralised' 的看法：你将工作加载到数据库中，这就是他们所在的地方。
对我来说，Ansible 适用于 devops - 因此以高度可重复的方式构建和自动化部署（自建）应用程序。我认为 Ansible 更侧重于构建自己产品的软件开发公司：Ansible 'playbooks' 是文本文件，因此通常存储在源代码管理中并且通常与剧本将部署的应用程序一起存储。
创造就业重点
使用 Rundeck，您通常可以通过网络创建工作 UI。
使用 Ansible，您可以通过文本编辑器在文件中创建 tasks/playbooks。
Operation/Task/Job风格
默认情况下，Rundeck 是命令式的 - 您编写的脚本将被执行（通过 SSH）。
Ansible 既是命令式的（即执行 bash 语句）也是声明式的，所以在某些情况下，比如说，启动 Apache 你可以使用 service 任务来确保它是 运行宁。这更接近于 Puppet 和 Chef 等其他配置管理工具。
复杂作业/脚本
Rundeck 可以通过在作业的工作流程中定义一个步骤来 运行 另一项作业，但从经验来看，这感觉像是附加功能，而不是重要的顶级功能。
Ansible 旨在创建复杂的操作； running/including/etc 是顶级功能。
如何 运行s
Rundeck 是一个服务器应用程序。如果你想从其他地方 运行 工作（比如 CI），你需要调用 cli 或进行 API 调用。
Straight Ansible 是命令行。
附带条件
由于 Rundeck 和 Ansible 的交叉和整体灵活性，您可以在每个中实现上述所有目标。您可以通过将 Rundeck 作业导出到 YAML 或 XML 并将它们签入源代码管理来实现对 Rundeck 作业的版本控制。您可以使用 Tower 在 Ansible 中获得一个网络 UI。等等等等等等
您的问题：
辅助工具？
我可以设想 SaaS 商店同时使用这两种方法：可以使用 Ansible 执行所有部署操作，然后使用 Rundeck 执行一次性的临时作业。
但是，虽然我可以设想它，但我不建议将其作为起点。我，我会从 Ansible 开始，看看我能走多远。如果我发现我真的 真的 需要 运行 一次性，我只会在 Rundeck 中分层。
CI/CD
Ansible：您的环境听起来更像是一个软件屋，您可以在其中部署自己的应用程序。它可能应该是可重复的（尤其是当你要持续交付时）所以你会希望你的部署脚本在源代码控制中。你会想要简单，而 Ansible 是 "just text files"。我希望您也希望您的开发人员能够 运行 在他们的机器上进行操作（对吗？），Ansible 是去中心化的。
一起使用(for CI/CD)
从 Ansible 调用 Rundeck，没有。当然，这是可能的，但我正在努力想出充分的理由。至少，不是非常专业的特定于特定应用程序或框架的原因。
从 Rundeck 调用 Ansible，是的。我可以设想有人首先在 Ansible 中构建一些可重复的临时命令。然后我可以看到有一些需求能够在没有命令行的情况下调用它（比如：非技术用户）。但是，这又是针对您的环境的。
服务器标准变得可行。
Adhoc/operation 任务进入跑道。
这是我目前使用的
如果您打算将它们用作开发人员或 OPS 团队的自助服务门户 那么我会说 RBAC 在 Tower 中而不是在 Rundeck 中实现更简单，直观上更清晰。考虑设置 RBAC 需要付出多少努力和复杂性，因为它对于支持此产品的团队至关重要。
REST API 在 Tower 中比在 Rundeck 中更简单、更容易解析。
在 Tower 中，您可以看到每个 playbook 任务的单独事件，而在 Rundeck 中，所有内容都在一个控制台输出中抛出。
Tower 中的动态清单对于 public 云中的部署非常有用。
我的观点 - 运行deck 和 ansible（免费，没有塔）做不同类型的工作
Ansible（无塔）- 配置管理（服务器/应用程序提供，批量配置更新）
Rundeck - 具有访问控制、通知、作业输出等功能的集中式作业调度程序（存档旧日志、运行 一些脚本等）
在提出这个问题时，作者正确地指出 Ansible 只提供了一个 UI 收费。
UI现已开源：AWX