Red Hat previews Ansible Automation Platform 2, turns Tower into Automation Controller

Ansible Automation Platform 2.0

It’s Ansible Fest time, so Red Hat used the opportunity of seeing friends of the automation tool assembled to present them with the changes in the upcoming second major release of its Ansible Automation Platform (AAP). 

In the past, AAP combined Red Hat Ansible Tower and Red Hat Ansible Engine with “use-case specific capabilities for Microsoft Windows, network, security, and more, along with Software-as-a-Service (SaaS)-based capabilities and features for organization-wide effectiveness”. However, the project’s architecture changed quite a bit under the hood, leading to a different sort of setup for version 2.0.

With the release of the early access preview of Ansible Automation Platform 2, Red Hat officially debuted Automation Controller as the new name for Ansible Tower. The renaming was thought necessary after the Tower team split the project into a control plane (the automation controller) and automation execution environments which are all part of the automation platform. 

Automation execution environments are described as self-contained images for automation, which are supposed to be more predictable than the Python virtual environments that were previously used. Images can be found in the company’s Container Registry and users need to familiarise themselves with the Ansible Builder tool introduced in late 2020 in order to get them working. 

AAP 2.0 also won’t be shipped with Red Hat Ansible Engine anymore, but includes an Ansible Core package as part of the execution environments (as well as a standalone). Another tooling change means that AAP 2.0 comes with a version of Ansible Navigator. Users should be aware of this, given that it means ansible-navigator run replaces the ansible-playbook command.

Where to go from here

Red Hat promises to support the old Ansible Tower through November 2022. This might well be necessary, given that AAP 2.0 doesn’t come with support for isolated nodes — meaning users will surely have to plan a little to upgrade safely. Customers banking on the feature will have to wait for version 2.1, expected in November 2021, since it is planned to sport remote execution nodes as an alternative approach. 

This detail was shared by Red Hat Principal Software Engineer Shane McDonald in a Q&A at Ansible Fest. According to McDonald, execution nodes can be thought of as an evolution of Tower’s isolated nodes, which can be chained together to form an automation mesh that will be part of the 2.1 release. Another option for isolated node users not willing to wait would be to move to an approach based on container groups and OpenShift — though this might not be feasible for VM users, for instance.

Automation mesh isn’t the only feature that is going to slip into AAT a little later in the year. The last quarter of 2021 is also supposed to see the addition of a centralised authentication service based on Red Hat’s SSO service, which larger organisations will surely appreciate. Moreover, there is a slight chance the team will add a slimmed-down on-premises version of the Automation Services Catalog as well as high availability support for the Private Automation Hub.

Ansible Automation Platform 2 is currently available in an early access version, with general availability of v2.1 planned for November 2021. The end of support for Ansible Automation Platform 1.2 is slated for November 2022.