AAP 2 dark flying As

Red Hat Ansible Automation Platform 2 is the next generation automation platform from Red Hat’s trusted enterprise technology experts. We are excited to announce that the Ansible Automation Platform 2 release includes automation controller 4.0, the improved and renamed Red Hat Ansible Tower.

Automation controller continues to provide a standardized way to define, operate and delegate automation across the enterprise. It also introduces new, exciting technologies and an enhanced architecture that enables automation teams to scale and deliver automation rapidly to meet ever-growing business demand.

Why was Ansible Tower renamed to automation controller?

As Ansible Automation Platform 2 continues to evolve, certain functionality has been decoupled (and will continue to be decoupled in 2.1) from what was formerly known as Ansible Tower. The naming change better reflects these enhancements and the overall position within the Ansible Automation Platform suite.

Who uses automation controller?

All automation team members interact with or rely on automation controller, either directly or indirectly.

  • Automation creators develop Ansible Playbooks, roles and modules.
  • Automation architects elevate automation across teams to align with IT processes and streamline adoption.
  • Automation operators verify that the automation platform and framework are operational.

These roles are not necessarily dedicated to a person or team. Many organizations assign multiple roles to people or outsource specific automation tasks based on their needs.

Automation operators are typically the primary individuals who interact directly with the automation controller, based on their responsibilities.

This blog highlights automation controller’s improved architecture, enhancements and how these benefit you.

An improved architecture

Automation controller’s improved distributed architecture enables automation operators to deploy instances over diverse platforms and scale automation rapidly to meet growing volume demands.

Let’s compare the previous Ansible Tower architecture to the updated controller architecture.

Previous Ansible Tower 3.8 architecture

Ansible Tower architecture

Rigid and tightly coupled

Automation teams need to deliver outcomes autonomously and, at other times, in coordination and collaboration.

The Ansible Tower architecture tightly coupled the control and execution plane, which can increase overhead and inefficiencies when scaling to meet high demand.

For example, let’s imagine the networking team creates new automation content that relies on the netaddr 0.7.20 Python package. The security team, however, has developed their automation using a later version of netaddr. Both teams need a unique netaddr version to execute their automation successfully.

Automation operators spend significant time confirming that the different versions of netaddr are available and consistent across Ansible Automation Platform instances or jointly manage these dependencies with these teams.

Imagine the overhead required to make sure consistent execution multiplies as more teams join, deployed instances increase, and automation content expands.

Inconsistent execution 

Automation teams need to verify that automation content executes consistently across the enterprise.

Operators need ancillary tools to deploy and manage dependencies across separate Ansible Automation Platform instances for consistent automation execution. These dependencies can include Python packages, Python versions, frameworks and Ansible content.

Ansible Tower used Python virtual environments to manage dependencies, but this method introduced challenges.

  • Managing Python virtual environments across multiple Ansible Tower instances slowed development cycles, as additional effort was needed to prevent inconsistent non-production and production systems.

  • Confirming custom dependencies were consistent across Ansible Tower instances grew in complexity as you increased deployments and as more users interacted with it.

  • Python virtual environments were challenging to port across Ansible Tower instances and tightly coupled to the control plane.

  • There are no tools supported and maintained by Red Hat to manage custom dependencies across Ansible Automation Platform deployments.

We’ve listened to and acknowledged your feedback. Scaling your automation was difficult. In response, we’re introducing an improved, distributed architecture.

The new, improved automation controller 4.0 architecture

Automation teams need to provide automation rapidly where and when the business needs it. They need to help their organizations automate for growth. 

Automation controller introduces a distributed, modular architecture with a decoupled control and execution plane. It enables teams to scale and deliver automation with reduced overhead and increased velocity.

 

Automation controller 4.0 architecture

Automation execution environments

Portability is reliability

Ansible Automation Platform 2 introduces automation execution environments. These are self-contained images in which all automation runs, including Ansible Core, Ansible content, and any additional dependencies.

Automation execution environments

Using automation execution environments, automation can run consistently across multiple platforms. All custom dependencies are defined at the development phase and are no longer tightly coupled to the control plane, resulting in faster development cycles, scalability, reliability and portability across environments.

For more insight into automation execution environments, please refer to this blog written by Anshul Behl.

PostgreSQL 12

Ansible Automation Platform 2 ships with PostgreSQL 12 installed from Red Hat Enterprise Linux 8 modules by default.

PostgreSQL 12 introduces a host of significant improvements. Most notably, Ansible Automation Platform 2 uses partitioned access for enhanced performance.

Automation controller installation

Automation teams need a single automation solution that spans the hybrid cloud.

Ansible Automation Platform 2 continues to provide a familiar installation experience across physical, virtual and containerized environments.

Ansible Automation Platform Operator

Ansible Automation Platform 2 introduces the Ansible Automation Platform Operator, which provides a cloud-native, push-button deployment of new Ansible Automation Platform instances in your OpenShift environment. It simplifies data management, migration and platform upgrades.

Additionally, the resource operator makes it easier to integrate automation into your cloud-native processes.

User interface experience

Automation controller’s user interface features a host of improvements while providing a familiar experience, easing migrations and the adoption of Ansible Automation Platform 2.

PatternFly 4

The interface uses the PatternFly 4 framework. This change enables increased performance and consistency with other Ansible Automation Platform 2 components and Red Hat offerings.

Automation controller 4.0 dashboard

Improved observability, interaction, and security

The improved interface introduces distinct view and edit perspectives for automation controller objects and components — a frequently requested capability in our customers’ feedback.

Distinct view and edit perspectives

Automation controller also provides intuitive filters that automation operators can use to display concise information relevant to the task at hand. The Ansible Automation Platform Operator filters the automation controller 4.0 Job output to display 'Host Unreachable' events in the example below. This makes it easier to identify and remediate the errors.

 

Automation controller 4.0 job output filter

Content Security Policy

The automation controller’s interface redesign includes a strict Content Security Policy adding an additional layer of protection that detects and mitigates common cybersecurity threats.

Additional enhancements

Automation controller 4.0 introduces improvements throughout the platform, including the browsable API, role-based access control, job scheduling, integrated notifications, graphical inventory management and workflow visualizer functions.

Here are several enhancements not covered in this blog:

  • Automation controller uses Python 3.8

  • Nginx has been updated to version 1.18 and uses RHEL 8 cryptography profiles.

  • Automation operators can disable the ability to add local users to automation controller 4.0 and only allow authentication via a configured identity provider.

  • Automation controller 4.0 provides new Prometheus metrics for tracking and debugging job event performance.

  • An additional awx-manage subcommand allows operators to extract host automation details.

  • GitHub Enterprise is a supported identity provider.

Please review the automation controller release notes for more information on all the changes automation controller 4.0 introduces.

Migration considerations

Ansible Automation Platform 2 provides exciting new capabilities. These changes, however, also bring new requirements and dependencies that need careful consideration before migrating to Ansible Automation Platform 2. Below are some key considerations related to the topics covered in this blog, but please be sure to review all the requirements on the automation controller install page.

Will Ansible Automation Platform 2 support isolated nodes?

While Ansible Automation Platform 2.0 (available now) does not support isolated nodes, the Ansible Automation Platform 2.1 roadmap includes this functionality and is planned for release in November 2021.

Does Ansible Automation Platform 2 support previous PostgreSQL versions?

No. PostgreSQL 12 is currently the only supported database for Ansible Automation Platform 2. Please keep this in mind as you develop your organization’s migration plan.

Do I need Red Hat OpenShift to run execution environments?

No. It is key to our mission that Ansible Automation Platform supports all Red Hat platforms. Ansible Automation Platform 2 can be deployed on Red Hat Enterprise Linux (x86_64), Red Hat OpenShift, or a combination of both to suit your needs - in the data center, cloud or at the edge.

What operating systems are supported for Ansible Automation Platform 2 installation?

Ansible Automation Platform 2 supports Red Hat Enterprise Linux 8.3 (x86_64) or later for installation on physical or virtual environments.

Key takeaways

Many organizations do not realize the full potential of automation because they aren’t able to scale.  

Automation volume demand is increasing as IT systems continue to evolve and automation adoption grows. Automation controller 4.0 features new capabilities focused on empowering automation teams to scale and satisfy this demand.

Our goal is to simplify your Ansible Automation Platform 2 migration and adoption. As we introduce automation controller 4.0 and its capabilities, we provide the familiar experience automation teams are accustomed to and continue to support multiple installation platforms - physical, virtual and containerized.

Automation controller’s new architecture leverages automation execution environments, simplifies dependency management, helps improve reliability and consistency, and accelerates delivery across Ansible Automation Platform instances.

Automation controller’s upgraded user interface provides better security, performance and improves observability with new filtering capabilities and distinct views.

The Ansible Automation Platform Operator provides cloud-native deployment and management of your Ansible Automation Platform 2 instances on Red Hat OpenShift. Additionally, the resource operator simplifies integrating automation with your cloud-native processes.

The Ansible Automation Platform 2 release, which includes automation controller 4.0, introduces a host of new, exciting technologies and improves the familiar experience for automation teams, business decision-makers and end-users alike.

Red Hat Ansible Automation Platform

Where to go next


About the author

Craig Brandt is a Principal Technical Marketing Manager for Ansible Automation Platform. Prior to this position, Craig served as a Solution Architect representing Red Hat at the IBM Services Integration Hub. He focused on large, complex deals that covered EMEA, LATAM and Canada regions. He brings over 16 years of experience in the IT field that covers automation, containerisation, management, operations, development and solution design

Read full bio