Is it a good idea to make Ansible and Rundeck work together, or using either one is enough?

Question

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 about 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 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 deploy 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 Ansibl 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.

Solution 1

TL;DR - given your environment of Jenkins for CI/CD I'd recommend using just Ansible.

You've spotted that there is sizeable cross-over between Ansible & Rundeck, so it's probably best to concentrate on where each product focuses, it's style and use.

Focus

I believe Rundeck's focus is in enabling sysadmins to build a (web-based) self-service portal that's accessible to both other sysadmins and, potentially, less "technical"/sysadmin people. Rundeck's website says "Turn your operations procedures into self-service jobs. Safely give others the control and visibility they need.". Rundeck also feels like it has a more 'centralised' view on the world: you load the jobs into a database and that's where they live.

To me, Ansible is for devops - so building out and automating deployments of (self-built) applications in a way such that they are highly-repeatable. I'd argue that Ansible comes more focussed for software development houses that build their own products: Ansible 'playbooks' are text files, so normally stored into source control and normally alongside the app that the playbooks will deploy.

Job creation focus

With Rundeck you typically create jobs via the web UI.

With Ansible you create tasks/playbooks in files via a text editor.

Operation/Task/Job Style

Rundeck by default is imperative - you write scripts that are executed (via SSH).

Ansible is both imperative (i.e. execute bash statements) but also declarative, so in some cases, say, starting Apache you can use the service task to make sure that it's running. This is closer to other configuration management tools like Puppet and Chef.

Complex jobs / scripts

Rundeck has the ability to run another job by defining a step in the Job's workflow but from experience this feels like a tacked-on addition than a serious top-level feature.

Ansible is designed to create complex operations; running/including/etc are top-level features.

How it runs

Rundeck is a server app. If you want to run jobs from somewhere else (like CI) you'll either need to call out to the cli or make an API call.

Straight Ansible is command-line.

Proviso

Due to the cross-over and overall flexibility of Rundeck and Ansible you could achieve all of the above in each. You can achieve version control of your Rundeck jobs by exporting them to YAML or XML and checking them into source control. You can get a web UI in Ansible using Tower. etc. etc. etc.

Your questions:

Complementary tools?

I could envision a SaaS shop using both: one might use Ansible to perform all deployment actions and then use Rundeck to perform one-off, adhoc jobs.

However, while I could envision it I wouldn't recommend that as a starting point. Me, I'd start with just Ansible and see how far I get. I'd only layer in Rundeck later on if I discovered that I really, really need to run one-offs.

CI/CD

Ansible: your environment sounds more like a software house where you're deploying your own app. It should probably be repeatable (especially as you're going Continuous Delivery) so you'll want your deploy scripts in source control. You'll want simplicity and Ansible is "just text files". I hope you will also want your devs to be able to run things on their machines (right?), Ansible is decentralised.

Used together (for CI/CD)

Calling Rundeck from Ansible, no. Sure, it would be possible but I'm struggling to come up with good reasons. At least, not very specialised specific-to-a-particular-app-or-framework reasons.

Calling Ansible from Rundeck, yes. I could envision someone first building out some repeatable adhoc commands in Ansible. Then I could see there being a little demand for being able to call this without a command line (say: non technical users). But, again, this is getting specific to your environment.

Solution 2

My point - rundeck and ansible (free, without tower) do different kind of job

1. Ansible (without tower) - configuration management ( server / app provision, mass config updates)

2. Rundeck - Centralized job scheduler with access control, notification, job output etc. (archive old logs, run some scripts etc.)

Solution 3

At the time this question was asked the author correctly stated that Ansible only provided a UI for a fee.

The UI has now been open-sourced: AWX

Solution 4

It is solely based on your requirements. I use rundeck for remote script execution and app deployments. I've integrated it with Foreman to cover the provisioning and configuration management.

If you have budget constraints look no further, Rundeck rocks. You may miss some features in Ansible though. Also the Google group is pretty much very active in case of support.

If you have budget invest in ansible tower and you may not need anything else.

Solution 5

Server standards go ansible.

Adhoc/operation task go rundeck.

This is what I currently use.

View more solutions

Comments

[ThoFin]

maybe that is a help link

[ingyhere]

This is really an opinion based question, so it's unlikely to add significant value from that standpoint.

[Gautam Jose]

Is you requirement satisfied? Which did you choose finally?

[shizhz]

I really want to give Ansible a try, even without Ansible Tower for now. Currently I just want to use Jenkins to trigger the deployment, which is one step in the whole CD pipeline.

[shizhz]

Thanks @otupman for your answer, for now we decided to use just Ansible in our company, as you said Ansible with Jenkins is a good combination. Maybe we'll also try Rundeck in the future when we really need it but not now:-)

[ingyhere]

Here are some great reasons to run Ansible from Rundeck: (1) Log history of deployments -- You can go back and review the logs when something goes wrong or to just view what was actually deployed. (2) Devs, managers and other stakeholders can own deployments on their own application tier. (3) It's easy to use. (4) It actually runs on a Windows box which Ansible cannot.

[Luís Guilherme]

Welcome to Stack Overflow, Petr. I suggest that you edit your answer to be more organized and more thorough (add examples, improve your formatting, etc.). It's a good answer, and making these edits will improve it and help your reputation here.

[Robert Kelly]

#2 is huge! Giving people who don't want to use a CLI the power to own these deployments is hugely beneficial. It allows you to hand off this responsibility to QA/build managers once you've gotten thing sewed up nicely, why should we have to click the button if we know that it works?

[otupman]

Indeed, #2 great. But if you're practicing Continuous Deployment (CD) then there's a strong argument to not have a button or GUI ... because ideally your deployment should be validated and go out automatically - no need for a button. Also: #1 your deployment history is in source control (such as github releases) and not in a secondary system #3 easy for who to use? #4 Windows support on the control machine is there docs.ansible.com/ansible/intro_windows.html and with WinRM you can call into it

[NicolasW]

"here's a strong argument to NOT have a button or GUI" -> I could not disagree more : I can think of tons of reasons to have a GUI for application deployment : user authentication, role management, rollbacks, deployment of specific branches or versions to subsets of environments, release to production, etc. etc. Even with real CI I doubt we have that many folks out there deploying code automatically to prod environments after a commit or merge.