Ansible AWX & Automation Controller (Tower): — From CLI to a Control Room

① Why a platform — one laptop doesn't scale to a team

Meet Sneha, an L1 automation engineer at Infosys. She wrote a tidy backup.yml that pulls every branch router's config and saves it to Git. It runs perfectly — from her laptop, with her SSH key, when she remembers to run it. Then the team grows to six engineers, the auditors ask "who changed the Mumbai core switch last Tuesday?", and Sneha goes on leave the week the nightly backup was supposed to fire. Every one of those problems is the same problem: a single laptop is not a team.

Walk the five gaps. No RBAC: anyone with the repo and a key can run anything against production — there is no "this junior may run the backup but not the firewall push." No audit: when something breaks at 9 a.m., there is no record of who ran what overnight or what the output was. No schedule: the nightly backup depends on a human (or a fragile cron on one box that nobody owns). No secret management: the Vault password and SSH keys live in shell history, sticky notes and scattered laptops. No self-service: a NOC analyst who just needs to run one safe, approved task has to be handed root and the whole repo.

Here is the shift. AWX is the open-source upstream; Red Hat Automation Controller (the product formerly named Ansible Tower) is the supported build of the same idea. Both wrap a web UI + REST API + control plane around the very same Ansible engine. Your playbooks do not change. What changes is everything around the run: who can launch it, where the secrets live, when it fires, and what gets recorded.

The five gaps, one tap each

Tap each card — these five are exactly why teams stop running from laptops and stand up a platform.

② Core objects — Projects, Inventories, Credentials & Job Templates

The whole platform is built from a few objects that snap together. Learn these four and the rest is detail. Project = your playbooks, almost always backed by Git. Inventory = your hosts. Credential = your secrets, encrypted. Job Template = the runnable unit that binds the other three together. Let's take them one at a time, because the EX374 exam and your first day both live in this list.

A Project points at a Git repository and a branch. When you (or a schedule) hit Sync, the platform pulls the latest commit so the playbooks it runs are always the approved ones in version control. This is the part new users trip over: edit a playbook in Git, forget to Sync the Project, and your Job Template happily runs the old commit. An Inventory is the list of hosts the job targets. It can be static (hosts you type in or group by hand) or come from a dynamic source that queries a cloud account or a script and refreshes itself, so a newly built VM appears without anyone editing a file.

Credentials are where the platform earns its keep on security. They are stored encrypted and injected at run time — the engine drops the SSH key or vault password into the job's environment for the duration of the run and never shows it back in the UI. There are types that matter: a Machine credential (SSH login + become/sudo password for Linux), a Network credential (for network_cli-style device logins), a Vault credential (the password that decrypts your Ansible Vault files), and various cloud credentials (AWS, Azure, GCP keys). Pick the wrong type and the job can't authenticate even though the secret itself is correct.

Finally the Job Template ties it together: it says "run this playbook (from this Project) against this Inventory using these Credentials inside this Execution Environment," plus knobs like limit, verbosity, and optional survey prompts. Click Launch and it becomes a Job with a live, streamed log. That single bound, repeatable, logged unit is the heart of the whole product.

curl -sk -u admin:'redhat' \
  https://controller.lab.local/api/v2/job_templates/ | jq '.results[] | {id, name, project, inventory}'

{
  "id": 14,
  "name": "Nightly-Branch-Backup",
  "project": 7,
  "inventory": 3
}

③ Team features — RBAC, schedules, workflows, surveys & audit

Now the features that turn "a GUI for Ansible" into "a platform a team can trust." Start with RBAC. You grant roles — like Admin, Execute or Read — on specific objects to users or teams. So a NOC analyst gets Execute on just the "Restart-Service" Job Template and Read on its inventory — nothing else. They can run the one safe thing and can't touch the firewall push. This is least privilege, enforced by the platform instead of by trust.

Schedules let a Job Template fire on its own — "run the config backup every night at 02:00." No human, no fragile cron box. Workflows go further: the Workflow Visualizer lets you chain templates with branching — run the backup, and on success run the compliance check, but on failure page the on-call. You can even drop an approval node that pauses the workflow until a human clicks Approve — a built-in change gate. Surveys add safe, parameterised self-service: instead of editing the playbook, a user is shown prompts ("which site?", "dry-run or apply?") at launch, and their answers become variables. Notifications wire job start / success / failure (and workflow approval) to Slack, Microsoft Teams, email or a webhook.

Two more. The audit trail (the activity stream plus every job's saved output) answers the auditor's question permanently: every job records who launched it, when, against which hosts, and the full log. And the Execution Environment (EE) is the container the job actually runs inside — it bundles a pinned Ansible version, the Python libraries and the collections your playbook imports. Because every run uses the same image, "works on my laptop" stops being a thing: a job either has its EE or it doesn't, the same way for everyone.

---
- name: Nightly branch config backup
  hosts: branch_routers
  gather_facts: false
  connection: network_cli
  tasks:
    - name: Pull and save running-config
      cisco.ios.ios_config:
        backup: true
        backup_options:
          dir_path: /backups/{{ inventory_hostname }}
      register: result

    - name: Fail the host if 'no telnet' baseline is missing
      ansible.builtin.assert:
        that: "'transport input ssh' in result.backup_path | default('')"
        fail_msg: "Drift: telnet not disabled on {{ inventory_hostname }}"

PLAY [Nightly branch config backup] ********************************
TASK [Pull and save running-config] *******************************
changed: [br-mumbai-01]
changed: [br-pune-01]
TASK [Fail the host if 'no telnet' baseline is missing] ***********
ok: [br-mumbai-01]
failed: [br-pune-01]  => Drift: telnet not disabled on br-pune-01

④ A real flow — nightly backup, scheduled, credentialed & notified

Let's assemble everything into the flow you'll genuinely build in your first weeks: a nightly config-backup that runs against a dynamic inventory of branch routers, on a schedule, with a network credential injected, and the result posted to a Slack channel. Every object from sections ② and ③ shows up here in order, so this is also your revision.

The build, step by step. 1. Create a Project pointing at your net-automation Git repo, branch main, with Update revision on launch ticked so it always runs the latest commit. 2. Create an Inventory with a dynamic Source so new routers appear automatically. 3. Create a Network Credential holding the device login (encrypted). 4. Create the Job Template binding all three plus a network Execution Environment that has cisco.ios. 5. Add a Schedule on that Template for 02:00 daily. 6. Attach a Notification (Slack/Teams webhook) on success and failure. 7. Grant the NOC team Execute via RBAC so they can launch it manually too, but can't edit it.

ansible-navigator run backup.yml \
  -i inventory/branch.yml \
  --execution-environment-image ee-network-2.6 \
  --mode stdout --check

PLAY [Nightly branch config backup] ********************************
TASK [Pull and save running-config] *******************************
ok: [br-mumbai-01]
ok: [br-pune-01]
PLAY RECAP ********************************************************
br-mumbai-01 : ok=1  changed=0  unreachable=0  failed=0
br-pune-01   : ok=1  changed=0  unreachable=0  failed=0

Three gotchas that bite real teams on exactly this flow. Credential scoping: the Network credential and the Job Template must live in the same Organization (and the launching user must have a role on the credential) or the Template can't attach it. Project sync: if you forget Update revision on launch and don't Sync, the 02:00 run executes last week's playbook — schedule the Project sync too, or tick the box. EE images: a Template pinned to the wrong/old EE image fails with 'couldn't resolve module' or an ansible-runner version mismatch even though the playbook is perfect.

One sober note from 2025–2026: because the controller holds every credential and can run anything, it's a high-value target — patch it. CVE-2025-69534 is a denial-of-service in automation-controller (Ansible Automation Platform 2.6) triggered by malformed HTML-like input; Red Hat fixed it in a patch release. The lesson for you isn't the CVE number — it's that the platform that holds the keys to your whole estate has to be kept current and access-controlled, exactly the way you'd treat a Vault server.