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.

Kaylyn

maybe that is a help link – Fermanagh

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

Answer 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.

Bonehead

Thanks @Bonehead 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:-) – Kaylyn

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. – Lawrence

#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? – Telex

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 – Bonehead

"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. – Motte

Answer 2

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

Minion

Answer 3

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.)

Belle

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. – Duodenal

Answer 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.

Starch

Is you requirement satisfied? Which did you choose finally? – Starch

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. – Kaylyn

Answer 5

Server standards go ansible.

Adhoc/operation task go rundeck.

This is what I currently use.

Burks

Answer 6

1. If you are going to use them as as self service portal for developers or OPS team then I would say that RBAC is simpler and intuitively clearer implemented in Tower rather in Rundeck. Consider how much effort and complexity is required for setting RBAC as it can be crucial for teams supporting this products.

2. REST API in Tower is simpler and easier to parse rather than in Rundeck.

3. In Tower you can see individual events per playbook task while in Rundeck everything is thrown in one console output.

4. Dynamic inventories in Tower are quite useful with deployments in public clouds.

Penza

Answer 7

I work with both since they don't really overlap that much in my opinion. Ansible by itself can be thought of an easier way of writing scripts, since it provides modules to do complex tasks, some even do it stateful. Where Rundeck is perfect as a self-service portal among other things. Some use cases where Ansible by itself lacks

1. automated incident response
2. complex operation tasks by non-technicals (creating a demo instance for some potential customer)
3. limiting access for environments while performing required tasks (running a specific sql on db system without having access)
4. a central system to manage cronjobs (you can reuse the cronjobs and track logs and integrate with notification systems)

---

Doing this in Ansible is re-inventing the wheel and will take a lot of time. Personally, I am using them together but not always, because sometimes it is not required to do that. So it is a question about when to use them together, and definitely not either one of them is enough.

Aloha