Chapter 2: Introducing Ansible

Ansible distributions and AAP 2

You can get Ansible from the community, from Red Hat Enterprise Linux, or as part of Red Hat Ansible Automation Platform. The language is the same in every case; what differs is the tooling around it and who supports you when something breaks.

Three ways to get Ansible

Two pip packages from the upstream project:

Not supported by Red Hat.

Ships in the RHEL 9 AppStream repository. Supported, but only for content provided or generated by Red Hat products, such as rhel-system-roles, Insights remediation playbooks and OpenSCAP playbooks.

Ansible Core plus certified collections, ansible-navigator, execution environments, automation controller, automation hub and cloud services. This is what the course (and this guide) uses.

What you get with Automation Platform

A subscription adds a set of things that enterprises care about:

The components of AAP 2

Click a component to see what it does. The execution environment at the centre is the idea that ties AAP 2 together.

Red Hat Ansible Automation Platform 2 components: Execution environments sit at the centre: the same container image is used by developers and by production.

Ansible Core

The fundamental functionality: the YAML automation language, loops, conditionals and the other building blocks of playbooks, plus the basic command-line tools. AAP 2.2 provides Ansible Core 2.13 in the ansible-core RPM and inside its ee-minimal-rhel8 and ee-supported-rhel8 execution environments.

Ansible Content Collections

Ansible used to ship every module inside the core package ("batteries included"). As the number of modules exploded, that became hard to support, especially when people needed a newer or older version of one module than their Ansible version provided.

So modules moved into separate Ansible Content Collections: bundles of related modules, roles and plug-ins maintained by the same group of developers. Ansible Core itself keeps only the small ansible.builtin collection, which is always available.

Automation content navigator

ansible-navigator is the new top-level tool for developing and testing playbooks. It replaces and extends several older commands:

Older commandansible-navigator equivalent
ansible-playbook site.ymlansible-navigator run site.yml
ansible-inventory --listansible-navigator inventory --list
ansible-config dumpansible-navigator config
ansible-doc ansible.builtin.dnfansible-navigator doc ansible.builtin.dnf

Crucially, it separates the machine you work on from the environment that runs the automation, by running playbooks inside a container.

Automation execution environments

An automation execution environment (EE) is a container image that holds Ansible Core, Ansible Content Collections, and any Python libraries, executables or other dependencies your playbook needs.

When you run a playbook with ansible-navigator, you choose an EE to run it in. Once it works, you can hand the playbook and the same EE to automation controller and know that it has everything it needs to run in production. Custom EEs are built with ansible-builder.

Automation controller and automation hub

Automation controller (formerly Red Hat Ansible Tower) is the central place to run enterprise automation, with a web UI and a REST API. Automation hub at console.redhat.com provides certified collections that you download with ansible-galaxy (for ansible-navigator) or through controller. Installing controller and hub is outside the scope of this course and the exam.

Takeaway

Compare community Ansible, ansible-core in RHEL, and Ansible Automation Platform. Use the chapter lab to check this on a real host.