Is it a good idea to make Ansible and Rundeck work together, or using either one is enough?
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.
Answer
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.