Ansible Core provides the fundamental functionality used to run Ansible Playbooks. It defines the automation language that is used to write Ansible Playbooks in YAML text files. It provides the key functions such as loops, conditionals, and other Ansible imperatives needed for automation code. It also provides the framework and basic command-line tools to drive automation.

Red Hat Ansible Automation Platform 2.2 provides Ansible Core 2.13 in the ansible-core RPM package.

Historically, Ansible provided numerous modules as part of the core package; an approach referred to in the Ansible community as "batteries included". However, with the success and rapid growth of Ansible, the number of modules included with Ansible grew exponentially. This led to certain challenges with support, especially because users sometimes wanted to use earlier or later versions of modules than were packaged with a particular version of Ansible.

The upstream developers decided to reorganize most modules into separate Ansible Content Collections, made up of related modules, roles, and plug-ins that are supported by the same group of developers. Ansible Core itself is limited to a small set of modules provided by the ansible.builtin Ansible Content Collection, which is always part of Ansible Core.

This provides users with the flexibility to select different versions of collections, or different sets of collections, based on their needs. It also provides developers with the ability to update their modules on a separate cadence from Ansible itself.

Certain collections, Red Hat Ansible Certified Content Collections, are officially supported by Red Hat and its partners through Ansible Automation Platform.

Ansible Automation Platform 2 provides a new top-level tool to develop and test Ansible Playbooks, automation content navigator (ansible-navigator). This tool replaces and extends the functionality of several earlier command-line utilities, including ansible-playbook, ansible-inventory, and ansible-config.

In addition, automation content navigator separates the control node, on which you run Ansible, from the automation execution environment that runs it, by running your playbooks in a container. This separation makes it easier for you to provide a complete working environment for your automation code from deployment to production.

An automation execution environment is a container image that contains Ansible Core, Ansible Content Collections, and any Python libraries, executables, or other dependencies needed to run your playbook.

When you run a playbook with ansible-navigator, you can select an automation execution environment for it to use to run that playbook. When your code is working, you can provide the playbook and the automation execution environment to automation controller (formerly called Red Hat Ansible Tower) and know that automation controller has everything it needs to correctly run your playbook.

The default environment used in Ansible Automation Platform 2.2 provides Ansible Core 2.13 and many Red Hat Ansible Certified Content Collections to provide a user experience very similar to Ansible 2.9. Another advantage of automation execution environments is that you can also use them to run earlier versions of Ansible. Red Hat also supports an automation execution environment that provides Ansible 2.9 for compatibility with earlier versions.

Alternatively, you can use a new tool provided with Ansible Automation Platform 2 called ansible-builder to create your own custom execution environments.

Figure 1.1: User experience: Adapting execution environments to your needs

Automation controller, formerly called Red Hat Ansible Tower, is the component of Ansible Automation Platform that provides a central point of control to run your enterprise automation code. It provides a web UI and a REST API that can be used to configure, run, and evaluate your automation jobs.

In Red Hat Ansible Tower, the system was both the control node and the automation execution environment. If automation code required a different set of Python dependencies in the automation execution environment on Ansible Tower than the system provided by default, you had to manually set up a separate Python virtual environment (or "venv") for your automation code to use. This was difficult to manage, hard to distribute, required updates to the system running Ansible Tower, and scaled poorly.

The new automation controller design solves this challenge by separating the control node (providing the web UI and API) from the automation execution environments (now running in containers). You can deploy container-based automation execution environments from a container registry, and replacing them for a particular Ansible Playbook is a matter of a simple configuration change in the web UI. It is then easier to deploy the exact environment in which the developers expect their automation code to run.

Figure 1.2: Components of automation controller

Automation controller can run automation execution environments on remote nodes (execution nodes), communicating with them over the network using a feature called automation mesh.

Automation hub provides you with a way to manage and distribute automation content. A public service at console.redhat.com provides access to Red Hat Ansible Certified Content Collections that you can download and use with ansible-galaxy (for ansible-navigator) and with automation controller.

You can also set up a private automation hub. A private automation hub enables you to create your own curated set of Ansible Content Collections. It also provides a container registry that you can use for distributing your automation execution environments, if you do not already have one.

A private automation hub provides a centralized place for automation controller and the organization's Ansible developers to use to get automation content.

Figure 1.3: Creator experience: Working with Ansible Automation Platform

In addition to the hosted automation hub at console.redhat.com, two other hosted services are available.

Red Hat Insights for Red Hat Ansible Automation Platform help you understand what automation code you are running and whether it is successful. You can also use it to evaluate the positive impact of automation on your organization.

Automation Analytics helps to provide better insight into the performance of your automation infrastructure. You can use it to analyze how you use automation and what modules, playbooks, and workflows you most frequently use.

Automation controller and automation content navigator both support automation execution environments. This simplifies the transition from developing playbooks to running them in production, because there is no need to use virtual environments or to install modules and their dependencies on automation controller. You can customize execution engines to contain everything that your organization requires to execute its playbooks.

Provided that automation content navigator and automation controller have access to the same automation execution environments, the transition from development to production for your playbooks should be almost seamless.