Ansible Tower to AWX, twice
Why we left Tower
Ansible Tower 3.8.1, licensed per managed node.
The licence didn’t match how we actually used the platform. We were paying for an estate-wide entitlement while automation was concentrated in .
AWX gives you the same controller with no licence, in exchange for self-support. For our usage profile that trade was easy.
Move one: AWX on RKE2
The real work wasn’t the controller, it was execution environments. Tower’s virtualenv model let job templates depend on whatever happened to be installed on the controller host. Container images make every one of those dependencies explicit, which is the point and also the effort.
Then the platform decision changed
The telco project standardised on OpenShift.
RKE2 stopped being where new platform investment went. Keeping the automation controller on a cluster the organisation was moving away from meant maintaining a second Kubernetes distribution for one workload.
So: move again, roughly after the first move finished.
Move two: blue/green to OpenShift
There is no in-place path for an AWX instance between clusters. All the state that matters — job templates, inventories, credentials, job history, schedules — lives in PostgreSQL. So the migration is a database migration with a controller rebuilt around it.
Approach:
- Stand up AWX on OpenShift alongside the running RKE2 instance
2. 3. Freeze: stop schedules and job launches on the old instance
4.
pg_dumpfrom RKE2, restore into the OpenShift instance 5. Validate 6. Manual cutover 7. Old instance kept running but idle as rollback
Manual failover rather than automated, deliberately.
Where it landed
AWX 24.6.1, released 2 July 2024 — the last AWX release. Development is paused pending an architectural rewrite, with the maintainers stating that the existing application architecture limits their ability to change it. The awx.awx collection has been flagged as lacking active maintenance.
So after two migrations, the platform is stable, working, and static. A frozen release with no outstanding CVEs is operationally fine. But it turns the platform question from “does this work” into “when do we move, and to what” — which, given the history above, is a question worth answering before someone else’s decision answers it for us.
Successor options
AAP 2.x — Red Hat’s supported line, and now a natural fit given the estate runs OpenShift. Event-driven Ansible and certified collections are real advantages. Per-node pricing is the constraint, which is where this whole story started.
Ascender (CIQ) — downstream rebuild of AWX with commercial support, from the Rocky Linux vendor. Enterprise Licence Agreement pricing rather than per-node, which is a different cost curve for a growing estate. Ascender Pro adds an event layer, local content hub, and platform audit log. AWX-derived, so job templates and workflows carry over.
Semaphore UI — different philosophy. Go, MIT-licensed, single binary, no external runtime dependencies, backed by SQLite/MySQL/PostgreSQL, not Kubernetes-coupled. Treats Terraform/OpenTofu as first-class. Recent releases added extended RBAC and HA. Not an AWX drop-in — templates and workflows get rebuilt, not migrated.