How good is that making Ansible and Rundeck work together

Support
1

Recently I’m looking at Ansible and want to use it in projects. And also there’s another tool Rundeck can be used to do all kinds of Operations works. I have experience with neither tool and this is my current understanding of them:

Similar points

Both tools are agent-less and use SSH to execute commands on remote servers

Rundeck’s main concept is Node, the same as Ansible’s inventory, the key idea is to define/manage/group the target servers

Rundeck can execute ad-hoc commands on selected nodes, Ansible can also do this very conveniently.
Rundeck can define workflow and do the execution on selected nodes, this can be done with Ansible by writing a playbook
Rundeck can be integrated with CI tool like Jenkins to do deploy work, we can also define a Jenkins job to run ansible-playbook to do the deployed work
Different points

Rundeck has the concept of Job, which Ansible does not

Rundeck has Job Scheduler, which Ansible can only achieve this with other tools like Jenkins or Cron tasks

Rundeck has Web UI by default for free, but you have to pay for Ansible Tower

Seems both Ansible and Rundeck can be used to do configuration/management/deployment work, maybe in a different way. So my questions are:

Are these two complementary tools or they are designed for different purposes? If they’re complementary tools, why is Ansible only compared to tools like Chef/Puppet/Slat but not with Rundeck? If they’re not why they have so many similar functionalities?
We’re already using Jenkins for CI, to build a Continuous-Delivery pipeline, which tool(Ansible/Rundeck) is a better idea to use to do the deployment?
If they can be used together, what’s the best practice?
Any suggestions and experience sharing are greatly appreciated.

2

No idea about rundeck. One point though, tower is open source

3

Foreman Ansible also has logic to implement recurring tasks. Perhaps @dLobatog can tell you more if this is a viable alternative.

4

Rundeck is mainly an application for handling generic “jobs”, for one-shot or scheduled jobs.

It fits perfectly for in-house custom tasks/scripts/commands to be provided to differents users/groups with advanced access control and logging, notifications, failure-handling, AD/LDAP integration.

Its generic goal and its plugin engine allowed people to create plugins for differents tools and API : chef, puppet, ansible, REST, EC2, Nexus, Consul, and so on but without totally adapt to the original workflow of this tools.

Speaking about nexus & jenkins plugin, my opinion about plugins is that they usually fit too much basic use-cases. The same for rundeck plugin for jenkins, so we had to implement some custom logic in a API local to the rundeck server.

I m using rundeck with :

  • displaying in menu artifacts from Jenkins and running in-house script to push artifacts to nodes
  • using in-house api (< 50 PHP lines), I display differents dependent menus to select target nodes/environments/countries
  • combining job of jobs following user forms
  • pull from git and push to remote nodes (handwritten script but I m try to rewrite it as a rundeck plugin in shellscript :smile: )
  • tasks to run prepared SQL queries on different databases with access given to different users
  • ondemand custom configuration generation on different servers
  • ETL tasks from and to different datasources, as custom shell and python scripts, or just raw commands
    Our setup : rundeck with SSL authentication by Apache + rundeck authentication on LDAP + fallback on AD + fallback on localusers + additional group, advanced ACL to restrict access to different groups.

My general opinion on rundeck is that its an AMAZING software and absolutely under-rated. It s really one of the best open source enterprise automation/jobs/tasks tool, it has everything recurring jobs needs.

About the ansible plugin, we did not tried it yet because our migration to ansible did not start yet :slight_smile: Comparing AWX to it made us think that AWX fits better for extensive use of playbooks/roles, but we did not yet migrated our deployment to Ansible, so we tried none. I think in both case, some modifications will be required by rundeck plugin as by awx.

Our main concern is to provide userfriendly form to fill up variables required by Ansible playbooks/roles and awx seems to fit better than rundeck, probably because of it s generic architecture.

If you will have many custom jobs to schedule/run/follow with good access control and logging, and not so much ansible code, Rundeck will be the way to go.

If you have only ansible playbooks, give a try first to awx

If you have both (as we have), you ll probably finish with using both tools.

5

hows the node authentication maintained? tower gives us big challenges with powerbroker and scripting.

6

I tried ansible plugin on rundeck and it is straight forward. Except in our production environment, we use 2fa yubikey which is not supported the last time I checked. So I stopped testing it. WIth regards AWX, I’ve had several issues just trying to install it. I gave up since I’m loading with work to play with stuff. but I hope someone could give a decent comparison between the two.

7

It may be a very interesting Foreman blog post :slight_smile: If you’d be willing to write about it, it’s as easy as sending a markdown post to https://github.com/theforeman/theforeman.org/tree/gh-pages/_posts :wink: