Ansible AWX serves as the open-source upstream project for the Red Hat Ansible Automation Platform (RHAAP). In the broader ecosystem of enterprise automation, AWX functions as the foundational codebase upon which the commercial Ansible Tower—and subsequently the Ansible Automation Platform—is built. It is designed to transform a collection of standalone Ansible playbooks into a comprehensive, scalable, and manageable automation hub. By providing a web-based interface, a robust REST API, and a sophisticated role-based access control (RBAC) system, AWX enables IT teams to move beyond manual command-line execution toward a centralized orchestration model. This transition is critical for organizations managing infrastructure at scale, where the need for auditability, traceability, and secure credential management becomes a operational necessity rather than a luxury.
Conceptual Foundations of AWX and Red Hat Ansible Automation Platform
The relationship between AWX and the Red Hat Ansible Automation Platform (RHAAP) is one of upstream and downstream development. AWX is the open-source version, meaning it is the community-driven project where new features are developed, tested, and iterated upon. RHAAP is the enterprise-grade distribution that incorporates these features with the added benefits of Red Hat's professional support, stability guarantees, and integrated enterprise tooling.
The primary objective of AWX is to act as a hub for all automation tasks. While standard Ansible allows for the execution of playbooks via the command line, AWX introduces a layer of management that simplifies the operational overhead. One of the most significant advantages is the ability to manage credentials securely. In a standard Ansible environment, managing SSH keys or passwords across a large team can be a security risk. AWX solves this by allowing administrators to store credentials centrally and share them with specific users or teams. Crucially, this system allows a user to execute a playbook using a set of credentials without ever actually seeing or possessing the raw credentials themselves, effectively eliminating the risk of credential leakage during the automation process.
Beyond security, AWX provides a graphical interface for inventory management. This allows users to move away from static text files and instead synchronize their inventories with various cloud sources, ensuring that the automation engine always has an up-to-date list of target hosts. The system also maintains a comprehensive log of every job executed, providing a transparent audit trail that is essential for compliance in regulated industries. For those requiring programmatic integration, AWX exposes a detailed REST API, which allows external systems like Jenkins to trigger jobs, modify inventories, or extract status reports.
Architectural Analysis and Modernization
The architecture of AWX is designed to decouple the user interface from the execution engine and the data storage layer. This ensures that the system can scale horizontally and remain resilient during high-load automation bursts.
Component Breakdown
The functional flow of an AWX deployment can be traced through several distinct layers:
- AWX Web UI: The primary interface for users to interact with the system, manage projects, and trigger jobs.
- AWX API: The communication layer that translates UI actions or external API calls into instructions for the system.
- AWX Task Runner: The engine responsible for executing the actual Ansible playbooks against the target hosts.
- Ansible Playbooks: The YAML-based instructions that define the desired state of the managed nodes.
- Managed RHEL Hosts: The target servers (typically running Red Hat Enterprise Linux) where the automation is applied.
- PostgreSQL Database: The persistent storage layer that holds all configuration data, user roles, job history, and inventory details.
Within a modern deployment, these components (UI, API, Task Runner, and Database) are typically encapsulated within a Kubernetes environment. This allows the operator to manage the lifecycle of the AWX application as a set of pods, facilitating easier updates and scaling.
The Shift Toward Service-Oriented Architecture
Historically, AWX and Ansible Tower were built as monolithic applications. Even when they were "lifted and shifted" into containers, the core structure remained a tightly integrated codebase. This meant that all services were bundled together, creating a scenario where modifying a single component could inadvertently impact the stability of the entire system. This monolithic approach is fundamentally at odds with modern cloud-native standards, which prioritize modularity and flexibility.
Starting with the release of AWX version 24.6.1 in July 2024, the development team began a strategic refactoring of the application. The goal is to transition Ansible into a pluggable, service-oriented architecture. This architectural pivot allows the team to isolate core functionalities and strip away components that have expanded beyond the original scope of the product.
The immediate results of this refactoring include the breaking out of the following components into separate services:
- User Interface (UI)
- Inventory Management
- Credential Types
This modularity ensures that the project remains streamlined and purpose-driven. However, it also means that certain high-level features are being decoupled from the base AWX installation. For instance, Event-Driven Ansible (EDA) and the Private Automation Hub are now separate upstream projects that must be integrated manually into the environment. Similarly, the "Policy as Code" feature, while open-source, will not be included in the standard AWX download; instead, it will be provided as part of the commercial Ansible Automation Platform (AAP).
Deployment Guide on RHEL 9
Deploying AWX on Red Hat Enterprise Linux (RHEL) 9 is most effectively achieved using the AWX Operator on Kubernetes. The operator pattern automates the deployment, configuration, and management of the AWX cluster.
Hardware and Software Prerequisites
Before initiating the installation, the host system must meet specific minimum requirements to ensure the stability of the PostgreSQL database and the task runners.
| Requirement | Minimum Specification |
|---|---|
| CPU Cores | 4 Cores |
| System RAM | 8 GB |
| Disk Space | 40 GB |
| Operating System | RHEL 9 |
| Container Runtime | Podman or Docker |
Step-by-Step Installation Process
The deployment process involves setting up a local Kubernetes cluster (via Minikube), installing the necessary CLI tools, and deploying the AWX Operator.
Phase 1: Minikube and Kubernetes Setup
For those utilizing a single-node deployment, Minikube provides the simplest path to a functional Kubernetes environment.
- Install the necessary system packages to handle network traffic and connectivity:
sudo dnf install -y curl conntrack
- Download and install the Minikube binary:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
- Initialize the Minikube cluster. The following command configures the cluster with 4 CPUs, 6GB of memory, the Podman driver, and the ingress addon for network routing:
minikube start --cpus=4 --memory=6g --driver=podman --addons=ingress
- Verify the status of the cluster to ensure it is operational:
minikube status
- Install
kubectl, the Kubernetes command-line tool, to interact with the cluster:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install kubectl /usr/local/bin/kubectl
- Confirm connectivity to the node:
kubectl get nodes
Phase 2: AWX Operator Deployment
The AWX Operator manages the complex deployment of the AWX pods and the PostgreSQL database.
- Install Kustomize, which is used to customize Kubernetes manifests:
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
sudo mv kustomize /usr/local/bin/
- Create a dedicated workspace for the deployment files:
mkdir -p ~/awx-deploy && cd ~/awx-deploy
Integration with External Identity Providers
To maintain enterprise-level security, AWX can be integrated with external identity providers such as authentik. This allows organizations to leverage Single Sign-On (SSO) and centralized user management.
When configuring the integration, it is necessary to define the Fully Qualified Domain Names (FQDN) for both the AWX installation and the identity provider. For example:
- AWX FQDN:
awx.company - Authentik FQDN:
authentik.company
This integration ensures that user access is governed by the organization's central directory, and the RBAC system within AWX can then be mapped to specific groups provided by the identity provider.
Migration and Enterprise Strategies
As organizations grow, the transition from the open-source AWX to the commercial Ansible Automation Platform (AAP) often becomes necessary to gain access to professional support and integrated features like the Private Automation Hub.
Migration Pathways
Migrating to AAP involves the transition of the PostgreSQL database, which contains all the critical operational data, including job histories, inventories, and project configurations. Depending on the target environment, this migration can be performed in several ways:
- Virtual Machine (VM) Deployment: Traditional installation for stable, fixed-resource environments.
- OpenShift Operator: The gold standard for cloud-native deployments, leveraging Red Hat OpenShift for maximum scalability.
- Containerized RHEL: Using the operator on standard RHEL nodes.
The migration process typically requires expert assistance to ensure data integrity during the database transfer and to configure the networking for the new environment.
Conclusion: Analysis of the AWX Trajectory
The evolution of AWX from a monolithic "lift-and-shift" containerized application to a pluggable, service-oriented architecture marks a significant turning point in the history of IT automation. By decoupling the UI, Inventory, and Credential systems, Red Hat and the community are addressing the technical debt accumulated over the last decade. This shift is a direct response to the scaling requirements of the world's largest IT organizations, which are now managing millions of endpoints across diverse environments including IoT, cloud platforms, and network devices.
The strategic decision to move high-level features—such as Policy as Code and Event-Driven Ansible—into separate projects or exclusively into the commercial AAP distribution suggests a clear demarcation between "core automation" and "advanced orchestration." For the end user, this means that the base AWX project remains lean and performant, while the enterprise platform provides a comprehensive, integrated suite. The move toward a service-oriented architecture not only improves maintainability but also opens the door for more aggressive scaling and modular updates, ensuring that Ansible remains the dominant force in the automation landscape for the foreseeable future.