AWX: Web-Based Console Manager for Ansible
Tower of Power
Special Thanks: This article was made possible by support from Linux Professional Institute
After the acquisition of Ansible by Linux behemoth Red Hat, the development path of both Ansible – a software provisioning, configuration management, and deployment automation solution – and Ansible Tower – a web-based console for managing complex Ansible deployments – changed.
In true Red Hat style, in which open source projects are cherry picked, stabilized, hardened, and released with commercial support for their enterprise customers, the freely available version of Ansible Tower, AWX, arrived.
To avoid the blurring of definitions, I quote the opening introduction to the AWX ReadMe file for clarity: “AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is the upstream project for Tower, a commercial derivative of AWX.”
I stumbled across AWX when looking for a way to manage multiple playbooks providing idempotency, of which my definition in this case was running playbooks every 20 minutes on multiple servers to provide assurance of the integrity of their configuration for security and uptime. To be clear, by configuration management I mean the ability to affect configuration on servers (or devices) of all varieties in an automated, predictable, and, one hopes, more secure way. (Also see the “Configuration Management and Ansible” boxout.)
As well as the API, AWX can happily integrate with your ChatOps software (several popular flavors are included) and fire off all sorts of notifications, with a view to your DevOps efforts being significantly reduced when it comes to managing your myriad of playbooks.
In this article, I show you how to install AWX and run a project. AWX is not intended for production use, but it should still provide you with lots of useful functionality within your other environments.
Configuration Management and Ansible
With all the latest tech in play, an undeniably common problem arose: When you are responsible for administrating hundreds of servers, ephemeral or otherwise, trying to herd their cat-like personalities can be a harrowing experience. From this cortisol-increasing scenario came the need for, and the eventual birth of, configuration management as it is known today.
Configuration management matured as technology moved further into the cloud. Enterprises additionally faced an array of hybrid on-premises, yet cloud-integrated, data center solutions. As a result, technological goalposts moved as user demands changed over time.
The popular Ansible software provisioning, configuration management, and deployment automation tool has unquestionably assisted in the wide adoption of configuration management because of its accessibility and gentle learning curve relative to other tools, such as Puppet and Chef.
With the adoption of Ansible, the problem then became how to provide secure and centralized granular access to sometimes hundreds of Ansible playbooks to multiple departments in an organization. Additionally, each staff member might need a different level of access, with the ability to schedule playbook runs. Equally key to successful operations was being able to spot failures and unexpected changes to playbooks. The solution for conveniently managing complex Ansible deployments was Ansible Tower.
Spinning Plates
In this example I use a DigitalOcean “droplet” (their name for a server), which is very affordable to run for a few hours and then snapshot if you want to come back to a half-built solution later. A word to the wise, however: At the time of writing, even stopped droplets appeared to incur ongoing charges (unlike some cloud platforms), so destroy the droplet after creating a snapshot for posterity.
As mentioned, only a few relatively simple installation steps are required to fire up a handful of Docker containers. Your web interface is then automagically presented through a port on your host machine, with the initial credentials admin and password .
If you prefer, you can also effect a Kubernetes installation via Helm, the popular Kubernetes package manager, or indeed OpenShift or Docker Compose installations if you are that way inclined. For ease, I shall stick with Docker on this occasion. Should you decide to opt for an alternative installation route, you can find help on the AWX GitHub page.
System Requirements
The system that runs the AWX service will need to satisfy the following requirements:
- At least 4GB of memory
- At least 2 CPU cores
- At least 20GB of space
- A running Docker, OpenShift, or Kubernetes
- A minimum PostgreSQL version 9.4 if you choose to use an external database
Attack of the Clones
The first step is to get hold of the good stuff by cloning the repository. With the Git package installed, you can run the command:
$ git clone https://github.com/ansible/awx.git
On my Ubuntu 18.04 droplet, I run the command
$ apt install ansible
to install Ansible itself. Everything is pretty much ready to go and almost to the point at which you can run your installation playbook.