My last post on Linux security hardening briefly mentioned Ansible Tower. Ansible itself is very good at configuration management. It is lightweight, agentless and easy to get started with. But once you manage more than a few configuration items, more than a few target systems and work together with other administrators, Ansible as a command line tool doesn’t scale well.
Similar to how Red Hat Satellite replaced yum update in larger environments, Ansible Tower makes Ansible scalable and gives it a Web UI and REST API. The Ansible Tower Web site has a nice 2-minute overview, and below, I’ll walk you through installing and using Ansible Tower 3.
For this demo, we do a simple all-in-one installation. For production setups, Tower can be installed with an external database and in a redundant active/passive configuration.
- Set up a RHEL or CentOS 7 VM with at least 2 GB RAM and 20 GB disk space, 10 GB of which need to be available in /var.
- Enable the extras repository on CentOS 7 or rhel-7-server-extras-rpms on RHEL 7.
- Download the free trial version of Ansible Tower. After filling out a form, the download link will be emailed to you.
- Copy the downloaded tar.gz file to the system where you want to install Tower, extract it, and edit the inventory file:
tar xf ansible-tower-setup-latest.tar.gz cd ansible-tower-setup-* vi inventory
- Define the following passwords in the inventory file: admin_password, redis_password, pg_password. The password for the Redis in-memory database must not contain spaces or any of the following characters: @ : – \ /
- Execute the setup script. It will install all required packages and configure Ansible Tower, of course using an Ansible playbook.
The last line should look like this, with no failed actions:
PLAY RECAP ******************************************* localhost : ok=124 changed=55 unreachable=0 failed=0
- Access the Ansible Web UI by going to http://HOSTNAME/, replacing the hostname in the URL with the DNS name of your Tower VM, or its IP address. Log in as admin with the admin_password that you set in the inventory file.
- After logging in, you have to request a free trial license. This should arrive in an email within a few minutes. Save the attached file, upload it on the same Tower page, and you are ready to go.
A freshly installed Tower instance comes with an example Ansible playbook and inventory that allows you to run a simple hello world task against the Tower server itself.
Playbooks are not imported directly into Tower, they are part of a Tower project. A project typically points to a Git repository that Tower downloads through HTTPS or SSH.
A demo project has already been set up by the installer, but needs to be updated from GitHub before it can be used. Click the Projects link at the top and then the cloud icon next to Demo Project to download the repository.
During the Git update, a pulsing green circle will appear next to Demo Project. Once the update is done, it will turn solid green. If an error occurred, you can get more details through the Jobs link at the top of the page.
Next, we need to tell Tower against which hosts the playbook should be run. Under Inventories, localhost has been defined as part of the Demo Inventory. This allows us to run the hello world playbook from the Demo Project against the Tower server itself.
To access a host, Ansible needs credentials. These are a bit hidden in the UI. Click on the Settings icon in the upper right and then on Credentials.
The Demo Credential doesn’t define actual credentials, because the hello world playbook does not run any tasks on the target system. In a real-world scenario, an account with sudo permissions would be defined here, with its password or private SSH key.
Credentials entered in Tower cannot be read by users. Tower users can run jobs with the credentials, but they won’t know your root password or the private key of your service account.
To bring a project, inventory, credentials and playbook parameters together, Tower uses a job template, accessible through the Job Templates link at the top. An example already has been defined as Demo Job Template:
A job template can be launched manually with the spaceship icon on the Job Templates page. To schedule it for one time in the future or for periodic runs, use the calendar icon.
The job page you are redirected to will give you a continuous status update and the same text output that you would get from Ansible.
What’s more interesting though is the details at the bottom of the page. In a real-world scenario, this allows you to quickly see the hosts your playbook failed on, which tasks failed, and why. The search boxes allow you to look for specific tasks and hosts.
This only covers the basic features of Ansible Tower. For information on things like user and permission management, playbook parameters and dialogs to ask the user for them, see the excellent Ansible Tower documentation.