The initial architecture of Red Hat Ansible Automation Platform had a closely related Control Plane and Execution Plane, which were available as part of the Red Hat Ansible Tower. While it was possible to use different Python virtual environments, with different versions and components of Ansible, they were managed manually. As a result, the process was complex, tedious and error-prone, and required the involvement of the platform administrators.

Red Hat Ansible Automation Platform 2 can natively support many different execution environments (runtime environments), adapted to automate specific scenarios, devices or systems. The new architecture of Red Hat Ansible Automation Platform 2 provides a control layer using the Automation Controller, which replaced the Ansible Tower. The introduction of separation between the control layer and the executive layer ensures much greater flexibility, stability and predictability of the entire automation. The Execution Environment is a standalone RHEL (Red Hat Enterprise Linux) UBI (Universal Base Image) 8 image that performs automation tasks in the form of a running container. Such an image contains the appropriate version of Python and Ansible, along with all the necessary collections (Ansible Content Collections) or additional packages, frameworks and related dependencies.

In this way, each team can easily create automation tasks that are tailored to a specific and optimized runtime or execution environment, being sure that it will perform as well as the one used during the development and test.

The predefined and accepted execution environment ensures portability and predictable, stable and reliable automation, even in distributed environments. Thanks to the bi-directional Automation Mesh network, the Automation Controller can conveniently and securely, using overlay network technology and TLS-based encryption, communicate with distributed nodes supporting the execution layer, which may include physical and virtual servers running RHEL system or Red Hat OpenShift platforms.

As part of the subscription for Red Hat Ansible Automation Platform, we get access to several execution environments, which can be downloaded as special images. Red Hat also provides the Ansible Builder tool, with which such environments can be modified or created, and the Ansible Navigator tool, which provides an interface for editing, analyzing and inspecting execution environments and launching previously prepared playbooks in them.

In new version Ansible Core was also separated from Ansible Content Collections, which were previously shipped as a single entity. Ansible Core currently includes only the basic modules and command line tools of Ansible and its components, that allow YAML code to be interpreted and executed or the use of conditional expressions and loops. Previously, Ansible Core delivered a lot of additional modules that extended the available automation functions of Ansible. The number of these modules and its functionalities grew so quickly, that it became necessary to isolate them into separate packages, called Ansible Content Collections. A single collection is a set of modules, roles and additional plug-ins that together are used for a specific purpose, such as the automation of a selected device or system. This approach has many advantages. The execution environment can now only have collections that are required for specific automation tasks. This applies not only to the selection of specific collections, but also their exact versions. Thanks to the new, each of the collections can be developed, maintained and updated more independently of Ansible Core.

The Automation Hub was also expanded. Previously, it gave access to both community-created collections as part of Ansible Galaxy, as well as commercial ones created, maintained and supported directly by Red Hat and certified Red Hat technology partners, which include vendors of various commercial solutions, such as in Cisco Systems, F5 and VMware. Automation Hub has been equipped with built-in functions to limit available collections, including those of not always certain quality, which are widely shared by the community as part of Ansible Galaxy, what is good for security and stability reasons. Collections provided by Red Hat and Red Hat certified partners are supported in the Red Hat Ansible Automation Platform subscription. With the second version of the platform, the Private Automation Hub also appeared, which allows you to conveniently manage and share collections and images of execution environments within the same organization.

Finally, we cannot forget about additional cloud services available as part of the Red Hat Ansible Automation Platform subscription, which include among others Automation Services Catalog and Red Hat Insights for Red Hat Ansible Automation Platform.

Automation Services Catalog provides a self-service interface for non-technical or less technical personnel, based on ITSM (IT Service Management Solution) idea. With its help, they can in a controlled manner (without or with approval), independently create new services or systems within the local infrastructure and cloud environments.

Red Hat Insights for Red Hat Ansible Automation Platform provides additional analytical tools, whose goal is to deliver enterprise-wide information about the automation and impact of the automation on the whole enterprise. 

Despite all these changes, the method of creating automation code or running it by Ansible can be carried out in exactly the same way, as it was done before. However, it is worth remembering about the introduction of FQCN (Fully Qualified Collection Name) and new tools that improve the entire process. The changes introduced as part of Red Hat Ansible Automation Platform 2 better address the issues of automation in many big enterprises and organizations, hence they are a key element of larger environments or places where automation should be implemented in a consistent manner.