awx

A few days ago, the post Upcoming Changes to the AWX Project came across my feed. An innocuous title, but sometimes community-impacting changes are buried in posts like this. So, as an interested Ansible user, I read through the post.

In 1,610 words, almost nothing of substance was written.

A lot about how it's not 2014 anymore, so 2014-era architecture doesn't suit AWX. Then a big bold disclaimer at the bottom:

Before we conclude, we should be clear about what will not happen.

• We are not changing the Ansible project
• We are not adjusting our OSS license structure

Ultimately, we need to make some changes to the way our systems work and our projects are structured. Not a rewrite but a refactoring and restructuring of how some of the core components connect and communicate with each other.

Note: Please note that the Tower Operator this post references is currently in early alpha status, and has no official support from Red Hat. If you are planning on using Tower for production and have a Red Hat Ansible Automation subscription, you should use one of the official Tower installation methods. Someday the operator may become a supported install method, but it is not right now.

I have been building a variety of Kubernetes Operators using the Operator SDK. Operators make managing applications in Kubernetes (and OpenShift/OCP) clusters very easy, because you can capture the entire application lifecycle in the Operator's logic.

Since yesterday's announcement that Ansible had released the code behind Ansible Tower, AWX, under an open source license, I've been working on an AWX Ansible role, a demo AWX Vagrant VM, and an AWX Ansible Container project.

As part of that last project, I have published two public Docker Hub images, awx_web and awx_task, which can be used with a docker-compose.yml file to build AWX locally in about as much time as it takes to download the Docker images:

Ever since Red Hat acquired Ansible, I and many others have anticipated whether or when Ansible Tower would be open sourced. Ansible Tower is one of the nicest automation tools I've used... but since I haven't been on a project with the budget to support the Tower licensing fees, I have only used it for testing small-scale projects.

I wrote a guide for Automating your Automation with Ansible Tower, and it's both on the web and in Chapter 11 of Ansible for DevOps, and in the guide, I wrote:

For smaller teams, especially when everyone on the team is well-versed in how to use Ansible, YAML syntax, and follows security best practices with playbooks and variables files, using the CLI can be a sustainable approach... Ansible Tower provides a great mechanism for team-based Ansible usage.