Introducing Ansible Automation Platform 2
At the conference held at the end of September AnsibleFest 2021 we announced a new, second version of the Ansible automation platform, which we have been working on for two years. Today we will give a quick overview of the conceptual innovations and useful resources for Ansible Automation Platform 2, as well as start to get acquainted with its new features in a little more detail (and we will continue to do so in the next articles of this series).
What’s new in Ansible Automation Platform 2
First of all, in this release, we aimed to improve the fundamental components of the Ansible Automation Platform and make it easier and easier for automation content developers and automation platform administrators to automate enterprise-wide. Everything you know and love about Ansible Playbooks scripting remains largely unchanged. The actual implementation of the foundation on which automation scripts are created, managed and operated in large, complex IT environments has changed. It is clear that today an enterprise automation platform must be built and maintained with an eye to container and hybrid cloud environments.
So what’s fundamentally new in Ansible Automation Platform 2?
First, as part of the Ansible open source project, separation of Ansible content from Ansible execution… For this, the so-called Ansible Content Collectionsin which modules, plugins, roles and other Ansible components are stored in discrete atomic form.
Lately we’ve been mostly busy moving most of the Ansible content (modules, plugins) into collections that live and are maintained separately from open source Ansible project… The main plus here is that the content is now updated independently of the Ansible project itself. That is, it can be released continuously and asynchronously without touching the stable version of the Ansible components that are responsible for performing the automations.
Second, in Ansible Tower, the control plane is now separated from the execution plane, renaming the corresponding components to the automation controller and automation execution environments.
The Ansible Tower has been split into two components: the automation controller (control plane) and the automation runtime (execution plane). This is for greater scalability and predictability of enterprise-wide automation. By splitting the Tower into two components, we were able to run execution components not only on the management node, but also elsewhere, which is important for automation in hybrid cloud and container environments like Red Hat OpenShift. In the next version of Ansible Automation Platform, number 2.1, another important basic component will appear – the automation mesh (consider the same service mesh network, but for Ansible), which will replace isolated nodes in the Ansible Tower. And this is already much more interesting, since it opens up new automation options, for example, up to edge systems or direct ones, or automation in the cloud.
Third, new tools that empower those who automate in the enterprise.
In the past, Ansible content development was heavily dependent on the person who created and curated the content. Newer tools such as the ansible-navigator and the ansible-builder provide more consistency when working with content that is developed on a workstation targeting a specific instance of an automation controller. This is achieved through the use of automation runtimes – they are much more predictable, portable and scalable compared to virtual environments (virtualenv) Python, which are used in the old version of Ansible.
Useful Resources
Ansible Automation Platform 2 offers an improved architecture and a number of useful new tools to scale automation while maintaining the familiar Ansible user experience. We want to provide as much information as possible so that you can quickly learn the new features and begin to work out a migration strategy to the new Ansible platform (if applicable), the first public version of which, 2.1, is expected to be released later this year. So watch out the knowledge base on the Red Hat Customer Portalwhere the latest news and articles will appear. In addition, the following helpful resources are already available:
Automation runtimes
With the proliferation of IT automation in the enterprise, there is an increasing number of automation environments designed for specific commands and scenarios. And managing these environments becomes increasingly difficult, especially when the process begins to scale to the level of the corporate IT environment as a whole. And since automation is now a critical part of workflows, Ansible Automation Platform 2 addresses this issue as follows:
The Ansible Automation Platform administrator gains the ability to provide and manage automation runtime environments (see below for more details) for different groups of IT professionals, such as networkers and cloud users. For each of these groups, according to its role, only the corresponding automation content is set, but the same base image is used, and not a full-fledged separate automation environment.
An automation developer is guaranteed to have the same Ansible environment on his computer as in production so that he doesn’t worry about consistency and dependencies, but can focus on developing automation content.
Automation teams have the ability to define, create, and update their automation environments without requiring an automation platform administrator to make changes to the automation platform.
The creation and distribution of runtime environments is done through a Private Automation Hub to ensure consistency and ease of use across teams.
Third-party developers and partners are able to create their own automation runtimes for their users and customers using the recently released ansible-builder command line tool.
What are Automation Runtimes
For IT automation to succeed, it must be consistent and reliable. One of our customers had a separate group of Ansible Automation Platform administrators who supported over 40 virtual environments for various teams within the organization. These teams used different versions of Ansible, and, for example, networkers needed different sets of automation content (and dependencies) for specific devices, and developers created their own environments to test certain applications.
No platform level tools existed to support and maintain these environments, and all hope was only to document each specific python virtual environment. As a result, the number of environments began to spiral out of control, there was a drift between development and production environments, and as a result, the cost and complexity of automation began to rise. At the same time, the administrators of the automation platform had to somehow monitor all this and keep it in working order.
It is for such cases in Ansible Automation Platform 2 that automation runtimes appeared. These are atomic images on which all automation is executed. Automation runtimes contain the following things:
RHEL UBI 8
Ansible 2.9 or Ansible Core 2.11
Python 3.8
Required Ansible Content Collections
Python collections or binary component dependencies
This approach helps standardize how environments in which automation is performed are created and distributed. In a nutshell, Automation Runtimes are containerized images that simplify the work of Ansible platform administrators.
The Role of Automation Runtimes in Ansible Automation Platform 2.0
Automation runtimes are part of Red Hat’s vision of separating the control plane from the execution plane to make the platform more scalable for developers and administrators who need automation to work consistently across platforms. Therefore, all custom dependencies are now set during the design phase of the automation, rather than during administration or deployment. Separating execution and control functions can speed development cycles and improve scalability, reliability, and portability of automation across computing environments. Automation runtimes are what makes Ansible Automation Platform now support distributed architectures and enable enterprise-wide automation.
What is ansible-builder
So, now you know what automation runtimes are, what are their advantages and what is their role in Ansible Automation Platform 2. It remains to learn how to create them.
To enable content developers and Ansible platform administrators to take advantage of these frameworks, we have created a tool called ansible-builder that generates runtimes based on dependency information defined in various Ansible Content Collections as well as user defined.
Along with Ansible Automation Platform 2, a set of ready-made and supported automation runtimes appeared in the Red Hat Container Registry. You can use these images for a variety of purposes and are provided as part of an Ansible Automation Platform subscription. Supported automation runtimes are hosted in a parent repository called ansible-automation-platform-20-early-access at registry.access.redhat.com. The following pre-built environments are now available there:
Minimal (ee-minimal-rhel8) – contains Ansible-2.11 and is built on the basis Red Hat Universal Base Image 8 and python-3.8. This image contains no collections. It can be used as a baseline for building automation runtimes with their own collections or Ansible Certified Content Collections available from the Automation Hub.
Supported (ee-supported-rhel8) – The default image that comes with the automation controller. Represents a minimal image, plus Ansible Content Collections Supported by Red Hat…
Ansible 2.9 (ee-29-rhel8) – contains Ansible-2.9 and all required Ansible dependencies. Best suited for migrating to Ansible Automation Platform 2.0 from Ansible Automation Platform 1.2.
To create your own automation runtimes on top of the standard Ansible Automation Platform 2 images, you use the ansible-builder Runtime Builder.
You can read more about it and how to work with it in Ansible project blog and in documentation…
Who is ansible-builder for?
Automation runtimes are used by both Ansible content developers and automation platform administrators. Therefore, they both need to understand how to create such environments using ansible-builder. They can be created by developers and provided to administrators, or vice versa, but in any case, it must be remembered that the ultimate goal is to use the same runtime on both the development machine and the production, so that you no longer have to manually maintain many different python virtual environments.
Summing up
Ansible Automation Platform 2 includes many new features that complement the automation runtime concept and allow you to do, for example, the following things:
Build and distribute such environments using a private automation hub to ensure consistency and usability for different teams in your organization.
Empower third-party developers and partners to create custom automation runtimes for their users and customers using the recently released ansible-builder command line tool.
In the next articles in this series, we’ll go into more detail about the Automation Controller, Private Hub, Automation Navigator, and some considerations for migrating to Ansible Automation Platform 2.
