Ansible Tower (AWX)

The enterprise web UI and automation platform for Ansible. Schedule playbooks, manage inventories and credentials, control team access, and integrate with any CI/CD system via REST API.

Ansible Tower vs AWX vs Ansible CLI

AWX Quickstart with AWX Operator (Kubernetes)

# Prerequisites: kubectl configured, minikube or kind running
# Step 1: Install AWX Operator via kustomize
cat <<EOF > kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - github.com/ansible/awx-operator/config/default?ref=2.19.1
images:
  - name: quay.io/ansible/awx-operator
    newTag: 2.19.1
namespace: awx
EOF

kubectl apply -k .

# Step 2: Wait for operator pod
kubectl get pods -n awx -w

# Step 3: Create AWX instance
cat <<EOF | kubectl apply -f -
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-demo
  namespace: awx
spec:
  service_type: nodeport
  nodeport_port: 30080
EOF

# Step 4: Wait for deployment (~5 minutes)
kubectl logs -f deployments/awx-operator-controller-manager -n awx

# Step 5: Get admin password
kubectl get secret awx-demo-admin-password -n awx \
  -o jsonpath='{.data.password}' | base64 -d

Creating an Inventory and Running a Job Template

# Example inventory (static, in AWX UI or via API)
# Inventory → Source → Manual:
[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

# Example playbook stored in GitHub (linked via Project)
# playbooks/deploy-app.yml
---
- name: Deploy application
  hosts: webservers
  become: yes
  vars:
    app_version: "{{ deploy_version | default('latest') }}"
  tasks:
    - name: Pull latest Docker image
      docker_image:
        name: "myapp:{{ app_version }}"
        source: pull

    - name: Restart app container
      docker_container:
        name: myapp
        image: "myapp:{{ app_version }}"
        state: started
        restart: yes

REST API: Trigger a Job from CI/CD

# Get an API token (one-time)
curl -s -X POST https://awx.example.com/api/v2/tokens/ \
  -H 'Content-Type: application/json' \
  -u admin:your-password | jq '.token'

# Launch a Job Template (template ID 42)
curl -s -X POST https://awx.example.com/api/v2/job_templates/42/launch/ \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"extra_vars": {"deploy_version": "1.2.3"}}' | jq '{job_id: .id, status: .status}'

# Poll until complete
JOB_ID=123
until [ "$(curl -s https://awx.example.com/api/v2/jobs/$JOB_ID/ \
  -H 'Authorization: Bearer YOUR_TOKEN' | jq -r '.status')" != "running" ]; do
  echo "Job still running..."; sleep 10
done
echo "Job finished"

Building a Workflow Job Template

Workflow Job Templates chain multiple Job Templates together with success/failure branches. A common deployment workflow:

# Workflow DAG (configured in AWX UI's visual editor):
#
#  [Run Tests] --SUCCESS--> [Deploy to Staging] --SUCCESS--> [Run Smoke Tests]
#                |                    |                              |
#                |               FAILURE                        FAILURE
#                |                    v                              v
#             FAILURE         [Rollback Staging]           [Notify Slack: Failed]
#                v
#       [Notify Slack: Test Fail]
#
# Each node in the workflow is a Job Template with its own:
# - Playbook
# - Inventory (can differ per node)
# - Credentials
# - Extra variables (can pass outputs between nodes via set_stats)

AWX vs Semaphore

RBAC Best Practices

• Create Organizations to isolate teams — each org has its own inventories, credentials, and projects
• Grant developers "Execute" permission on Job Templates but not "Admin" — they can run but not modify
• Use Teams to apply permissions in bulk rather than per-user grants
• Restrict who can edit credentials — most users should only see that a credential exists, not its value
• Use the "Ask at launch" option for extra_vars sparingly — prefer defined variables in Job Templates for auditability