Ansible is a powerful tool, and as uncle Ben used to say: “with great power comes great responsibility” but as Wikipedia denotes it comes back from 1793 during the French Revolution.

But, how we let operators leverage this power? One can create a complicated permissions and sudo configuration scheme for less privileged users, but if we have a lot of them, and we want to allow them running different tasks on different systems it won’t be manageable.

The answer is using an interface which takes on these controls and implements the RBAC mechanisms, that interface is AWX.

The installation process

I followed the official guide, which was a step-by-step guide.

One of the initial steps was to complete the inventory file with actual information, I wanted to used the official images from Docker Hub, so very I only had to change the ports to non privileged ones.

As this deployment was meant to be ephemeral and not publicly accessible, I tried to keep the default passwords, but the ansible task complained.

After adding an admin_password variable to the inventory it stopped complaining, but when I ran the playbook it failed in one task, but the containers were running.

The web server was listening but the migration process was not running and the web interface was stuck on a Please wait loop. I googled and found I wasn’t the only one with this problem.

https://github.com/ansible/awx/issues/6539#issuecomment-609106337

The proposed solution was to run again the migration process manually:

docker-compose exec web awx-manage migrate --noinput

This process created the table schema on the database among other tasks.

Then the interface was being drawn correctly, but still inaccesible because the superadmin account was not created. So I had to create it by running another command.

docker-compose exec web awx-manage createsuperuser --username admin

juanjo@lab awxcompose $ docker-compose exec web awx-manage createsuperuser --username admin
Email address: juanjo@localhost
Password: 
Password (again): 
Superuser created successfully.

Once I ran those commands, I had my interface accessible.

Creating an organization

The first step was to create an organization, because it is required for instance to create an inventory.

Not much is required, only a name. After clicking the Save button I was redirected to the details page, where the creation and modification date were shown. It had a several tags, including “Access” and “Teams”. In the Access tab I found the user admin was automatically added, as I hadn’t created any user or team yet, I wasn’t able to add any of them to the permissions.

Creating credentials

Then I created the credentials, as I had several machines already configured from my Vagrant test, I used the same private key. That wasn’t an optimal setup, because of the root access, but it’s enough for a test.

The link to credentials administration is on the Resources section of the menu, it took me to an empty list with an Add button, to create a SSH key I chose Machine from the Credential Type dropdown, then filled the username and pasted the SSH Private key on the box. As the key wasn’t password protected, I left the passphrase box empty. And the same for the Become Method box, because I was using the root user.

Creating the inventory

The next step was creating the inventory, this is a multistep task, the first one is creating the inventory itself from, and then the hosts. After clicking save I was redirected to the details page, where a tab for adding hosts to the inventory was available.

Adding a host was simple, only the name was required, but I took advantage of the Variables section to add the IP address, as I wasn’t using a DNS server.

Creating the playbooks

The objective of AWX is to run playbooks and other ansible tasks on hosts, but, where are they on the interface?

There was no playbooks section on the interface, instead they are organized into projects and job templates. A project is composed of one or more playbooks, and AWX allows you to fetch them from git repositories, subversion, or other sources, but I wanted to use some playbooks which weren’t online.

On my first deployment of AWX I didn’t specify the projects path as a separate volume, I reran the installation with the path and then I had a local folder mounted on web and task containers as base path for projects.

Then I created a simple playbook with the following content:

---
- name: Hello World Playbook
  hosts: all 
  tasks:
    - name: Print hello world message
      debug:
        msg: "Hello world! And hello {{ runner | default('unknown') }}"

And went to the Projects section on the left menu, it showed me the empty list screen and I clicked the add button, I entered a name and a small description, choosed the organization and Manual on the Source Control Credential Type, and the directory where I put the playbook on the Playbook Directory combo.

I had problems with the directory detection, at first I used a variable for the hosts on the playbook, and AWX didn’t like it, after changing it I got stuck on browser’s caché, and the directory didn’t show until I hit Ctrl+F5.

But at that point I hadn’t playbooks yet, once the project was set, I went to the Templates section and created a new job template. Once selected the project, the Playbook combo was populated with the playbooks available, in my case there was only one.

One thing to care about at this page is the credentials selection, I missed it on my first attempt and I was unable to run the job until I discovered were to specify them. It was strange the credentials being tied to the template instead of the inventory, but there where they.

Launching the test job

After saving the job template, I was once again redirected to the details page, with a Launch button at the bottom, nothing more to say.

It took me a couple of tries, because of the credentials problem, but I finally managed to run the playbook from AWX.

Let’s call it a day.

Footnote

The AWX Project is a trademark of Red Hat, Inc., used with permission.