What's new with Ansible Automation Platform 2.0: Developing with ansible-builder and Automation execution environments.

Updated

Red Hat Ansible Automation Platform 2.0 is now available as an early access to customers. This release elevates automation across your organization, expanding the possibilities you can achieve. It is a more secure, flexible foundation on which to build and deploy automation that helps your business accelerate, orchestrate, and innovate.

As automation spreads throughout the organization, managing multiple automation environments for different teams and use cases becomes challenging. This is even more true as automation starts to scale across the IT organization. As automation continues to be part of critical workflows, the following enhancements have been made in Red Hat Ansible Automation Platform 2.0 release:

  • Enable the Ansible Automation Platform Administrator with the ability to provide and manage execution environments (see below) to differing groups like networking and cloud teams. Each has specific content needed for their roles to run instead of addressing different environments per individual.
  • Provide the Automation developers with a consistent ansible environment, that’s the same as production, so they can stop worrying about the automation environment and dependencies and focus more on the automation content itself.
  • Enable automation teams to define, build, and update their automation environments without requiring them to contact the platform administrator for changes to the platform.

What are Automation execution environments?


Having consistent, reliable automation is key to a successful automation initiative. One Red Hat Ansible Automation Platform customer had their internal administration team having to maintain over 40 different [virtual environments](https://docs.ansible.com/ansible-tower/3.8.2/html/upgrade-migration-guide/virtualenv.html) for different teams. Some used different versions of Ansible, network teams required different automation content (and dependencies) for their specific devices, and developers started building their own environments for testing.

With no platform tools for supporting and maintaining these environments other than documentation pointing to the de facto solution of specific python virtual environments, custom environments proliferate, drift happens between development and production, and the cost and complexity of automation increases. Furthermore, this burden is on the platform administrator to keep track of while maintaining everything as operational.

Ansible Automation Platform 2.0 introduces a new construct called “automation execution environments.” These are atomic images on which all automation is run. Automation execution environments contain the following:

  • RHEL UBI 8
  • Ansible 2.9 or Ansible Core 2.11
  • Python 3.8
  • Any content Collections
  • Collection python or binary dependencies.

This provides a standardized way to define, build and distribute the environments that the automation runs in. In a nutshell, Automation execution environments are container images that allow for easier administration of Ansible by the platform administrator.

Role of execution environments in Ansible Automation Platform 2.0


Controller 4.0 architecture

The move to automation execution environments is part of our approach to separate the control plane and execution plane going forward for better scalability for automation developers and administrators. Automation teams demand that their automation runs consistently across multiple platforms. All custom dependencies are now defined at the development phase and are no longer defined at the administration/deployment phase. Having the automation execution decoupled from the control plane results in faster development cycles, scalability, reliability, and portability across environments. Automation execution environments have enabled Ansible Automation Platform to move to a distributed architecture with the ability to scale automation across your organisation.

What is ansible-builder?


Now that you are aware of execution environments, their benefits and the role they play in Ansible Automation Platform 2.0 release, how do you actually build one?

To enable Ansible Content Creators and Ansible Platform Administrators to take advantage of automation execution environments, Content from www.ansible.com is not included.ansible-builder
was created, which aids in the creation of execution environments. It does this by using the dependency information defined in various Ansible Content Collections, as well as by the user.
Execution environments

With the release of Ansible Automation Platform 2.0, there are a set of prebuilt, supported execution environments available on the Red Hat Container Registry. These images can be used in different capacities in your organization’s environment and are provided as part of the Ansible Automation Platform subscription. The supported execution environments are hosted in a parent repository called ansible-automation-platform-20-early-access on This content is not included.registry.access.redhat.com. The following pre-built environments are now available:

  • Minimal (ee-minimal-rhel8 ) - Contains Ansible-2.11 built on top of This content is not included.UBI8 and python-3.8. This image doesn’t contain any Collections. You can use this image as the base image to build additional execution environments with your custom Collections or the certified Collections available on Automation Hub.
  • Supported (ee-supported-rhel8) - This is the default image available with the automation controller. It is built on top of the minimal image and contains content collections supported by Red Hat.
  • Ansible 2.9 (ee-29-rhel8) - Contains Ansible-2.9 and all the required ansible dependencies. This image is best for customers who are planning to migrate to Ansible Automation Platform 2.0 from Ansible Automation Platform 1.2.

ansible-builder is used to build custom execution environments by layering on top of the images provided with Ansible Automation Platform 2.0. Please check the upstream blog on ansible-builder and This content is not included.Customizing an Already-Existing Execution Environment Image section of the ansible-builder documentation to understand how to build your own execution environment on top of the default ones provided by Ansible Automation Platform.

Who will use ansible-builder?


An execution environment is the common artifact between the Ansible content creator and the automation platform administrator. They both should understand how to build them using ansible-builder. Content creators provide the platform administrator with execution environments or vice versa, but the common theme to keep in mind here is that the ultimate goal is to graduate the same execution environment from content creator’s development machine to the production environment. The result is no longer managing the multiple python virtual environments in a manual way.

Key Takeaways


The Red Hat Ansible Automation Platform 2.0 release includes a myriad of new features that are built to complement the concept of Automation execution environments. With the new release you can do the following:
  • Build and distribute automation execution environments via private Automation Hub, allowing consistency and usability across teams in an organisation.
  • Enable third-party developers and partners to create their own automation execution environments for their users and customers using the newly released ansible-builder command line tool.

Please visit the Ansible Automation Platform 2.0 Early Access home page hosted in the Red Hat Customer Portal for more information on how it adapts to maturing business needs and provides a unified solution focused on acceleration, consistency, and collaboration.

Where to go next

Product(s)
Category
Article Type