One of our clients recently wanted to start using Ansible on a project. As part of the new effort we wanted to investigate Ansible Tower as a potential way to use Ansible. This blog is a overview of the thoughts I had and some lessons learned. My next blog will be more specific examples of how to use Tower.
To better understand the basics of Ansible Tower, you must first understand a little about Ansible. Ansible is a configuration management (CM) tool, similar to Chef and Puppet. CM tools allow you to write code to easily and repeatedly set up computing environments as needed for your organization.
A common example being something like: You need NGINX installed on all developer laptops. You can easily write a playbook (what Ansible calls a simple install script, leveraging pre-written modules to accomplish your goal) to install NGINX. You can then use your Ansible server to push your NGINX playbook to each developer laptop. When you write and execute a playbook, Ansible uses SSH for remote access to the server(s) and leverages Python to execute pre-written modules; in this case you would probably use the “yum” module.
Ansible Tower is a piece of software that sits on top of an Ansible server to provide an easy and repeatable interface to Ansible code. Ansible commands can sometimes grow quite large to run, so having the playbooks runnable in a Tower GUI interface allows you to do great things such as creating users/user groups and permissions associated with the groups. It allows you to import already created playbooks and you can create them with inventories right there on the website.
Ansible Tower has an extensive API. They do not have good documentation on their website, but when you install Ansible Tower, you go to the URL: https://<tower>/api and you can browse through their API calls on your own server (Figure 1). This is great when you have time to browse around for what you want, but sometimes it can take a while to get to what you want; If you want to go that route (stay tuned for my next post where we dive into the APIs more).
However, if you do want to use Ansible Tower outside the GUI via a script or something like that, you can take advantage of the Python tool: ansible-tower-cli which you can install via “pip.” The CLI is documented better and is relatively simple to use. Here is its github page with some basic beginner use cases: https://github.com/ansible/tower-cli/. You can easily create users, create new job templates, and get statuses of currently running jobs.
In my opinion, the benefits to using Ansible Tower are: simplifying the use of Ansible, auditing, and security.
Let’s say you spend a lot of time developing Ansible playbooks and at some point want to pass them off to an Ops team to maintain. Tower has a function built into it, where you can point it to a playbook you have written, and it will read it into the Tower interface. From there you, you can use it as a general job template. So the Ops team can come in, and select your playbook, which servers to run it against (called an inventory), and other options and variables you can build in.
Tower can keep a history of the times that job has run, the successes/failures, logs, what servers you have run it against, and the status of those servers. Because it stores all this information, it makes auditing a breeze.
Furthermore, if you want to split up who in your Ops team can only do certain things, that’s built right into Tower. When you make each user you can change the scope of their account, you can associate keys with only that user or a group of users and so on. You can add a key or password through the GUI and Tower will store the hashed copy.
In conclusion, Ansible Tower is expensive but definitely has some upsides. It is fairly easy to get up and running and become a basic user and allows for an easy trade off between Ansible development and Ops.
There are other options to running Ansible. For instance, you can use something like Jenkins to just kick off Ansible playbooks instead, but Tower, being solely for Ansible, displays more useful information about previous runs and stores it in a more intuitive way.
