openskills.info
Ansible Automation Platform logoCourse Preview

Ansible Automation Platform

Ansible Automation Platform is Red Hat's supported suite for running Ansible at organizational scale. It adds a shared control plane, content repositories, role-based access, containerized execution, and event-driven automation around the playbooks and inventories Ansible already uses.

itInfrastructure and operations

Don't Panic — Ansible Automation Platform

Ansible Automation Platform is what you get when Ansible playbooks outgrow a laptop. The language stays YAML. The new machinery is a shared control plane: who may launch what, against which inventory, with which credentials, inside which container image, and with which retained job record afterward.

Before this product family, many teams lived in a familiar pattern. Someone with shell access on a control node ran ansible-playbook, kept inventories and vault files nearby, and hoped the next person used the same flags. That works until the second team arrives, or until someone needs proof of what ran last Thursday.

AAP's useful mental model is three planes behind a platform gateway login. Automation controller is execution: organizations, inventories, credentials, projects, job templates, workflows, and jobs. Automation hub (and private hub) is content: collections and execution environment images. Event-Driven Ansible is decisions: rulebooks that watch events and start work when conditions match.

The surprise for Ansible veterans is usually the runtime. In AAP 2 and later, jobs run inside execution environments, not in a carefully tended Python virtualenv on the controller host. Automation mesh then places those container runs on execution nodes so control capacity and execution capacity can grow on different curves. If you are still debugging "missing Python library" by SSHing to the controller, you are looking at the wrong plane.

A job template is the everyday object. It binds a playbook from a Git project to inventory, credentials, and an execution environment so a launch is repeatable. Workflows chain several of those launches when a release needs a graph, not a single play. Neither feature forgives a bad playbook; they only make a bad playbook easier to run at scale if RBAC and change practice are loose.

If you want the architectural map, read the Intro and Skim the Slides. Keep the Cheatsheet open when you are naming resources on a real controller. Use Field Notes when a migration to execution environments starts to feel longer than the UI tour suggested. The Reference tab points at Red Hat's current docs once you need install topology or field-level template behavior.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources