Requirements/scenerios of an automated system to run adhoc scripts/commands:
They both do almost the same thing out of the box: provide agentless commands to remote systems.
bolt fits in with puppet better, but both ansible and bolt solve this problem but do it in different ways:
bolt fits into the puppet ecosystem better, and is written in ruby.
ansible obviously does the same but is more mature in this field than bolt and is written in python.
Rundeck has a web UI that can be used to admin the system. However there are parts of that are still not in the UI and you have to configure on disk. This ends up being confusing.
Just using the Community/FOSS edition, passwords/keys aren't encrypted on disk.
In order to get certain plugins for Rundeck, we'd have to pay for the Enterprise edition. Pagerduty integration is limited in the Community edition.
The cost of one server and 5 users is $27,500 for the first year and $22,500 every year after that. We have not opened discussion about donated services.
RD is a complete system that we'd have to admin. While it can write files to disk for the "database" it prefers a relational DB. We'd also have to keep the web server up, monitored, etc.
Ansible Tower, which is similar-ish to Rundecks UI is not free. We haven't received a quote, though it's a Red Hat product, which we might be able to get donated.
However, that doesn't matter, Tower isn't required to be 100% running with this adhoc. Even if we got deeper with Ansible, Tower would be a nice to have not a need to have.
Running adhoc commands is so easy a cave man could do it(tm). To make it easier, we'd just have to have a repo that has inventory up to date and some additional configs.
Ansible is waaaaaay more light weight. We could either run things adhoc from our own systems or setup a very small VM to host this all and act as single point of entry. (this is an architecture thing we'd have to discuss between all of us)
There's more of a learning curve with Ansible playbooks/etc. Not by any means steep, but in RD you can just load the UI, click some UI bits and run a command that keeps track of the output, etc.
Ansible doesn't natively have the concept of schedules, though there are plenty of solutions.
They can be used together: https://www.rundeck.com/ansible
It's not a bad idea to use both, It could also be of value with packer, creating images locally and using one of the many ansible virtualization modules to launch it.
vagrant, packet and terraform all work together to provide all kinds of beneficial goodies and ansible is really easily compatible with all three.
terraform module -- https://docs.ansible.com/ansible/latest/modules/terraform_module.html#terraform-module
ansible and vagrant for local environment testing -- https://docs.ansible.com/ansible/2.3/guide_vagrant.html
packer has an ansible provisioner -- apply the load to your machine before creating the image.