Anshul Behl

Author Archives: Anshul Behl

The anatomy of automation execution environments

anatomy of EE blog

Red Hat Ansible Automation Platform 2 introduced  major architectural changes, like automation mesh and automation execution environments, that help extend Ansible automation across your organization in a flexible manner, providing a single solution to all your organizational and hybrid cloud automation needs.

Automation execution environments are container images that act as Ansible runtimes for automation controller jobs. Ansible Automation Platform also includes a command-line tool called ansible-builder(execution environment builder)that lets you create automation execution environments by specifying Ansible Content Collections and Python dependencies.

In general, an automation execution environment includes:

  • A version of Python.
  • A version of ansible-core.
  • Python modules/dependencies.
  • Ansible Content Collections (optional).

In this blog, I will take you through the inner workings of ansible-builder and how all the above requirements are packaged inside automation execution environments and delivered as part of Ansible Automation Platform.

 

A tale of two ansible-builder packages

As all projects in Red Hat, ansible-builder follows an open development model and an upstream-first approach. The upstream project for ansible-builder is distributed as a Python package, and then packaged into an RPM for Ansible Automation Platform downstream.This also means that there are different ways to install the upstream package and the downstream ansible-builder.

NOTE: Continue reading

Digitally signing Ansible Content Collections using private automation hub

Digitally signing content in Private Automation Hub

Red Hat Ansible Automation Platform can manage and execute automation made from many different origins, coming from Red Hat product teams, ISV partners, community and private contributors.

Here is a typical makeup of an automation play that is launched from automation controller:

  1. A job template is executed by automation controller and is a playbook.
  2. The playbook runs inside of an automation execution environment by the automation controller.
  3. The automation execution environment is made using the execution environment builder (ansible-builder tool).
  4. When ansible-builder creates the execution environment, it includes dependencies.
  5. The dependencies are Ansible Content Collections and their requirements.
  6. Collections and their dependencies can be private, community-based, or supplied by Red Hat or its ISV partners.

Previously, there was no way to verify that a Collection downloaded from either Ansible automation hub (console.redhat.com) or private automation hub was developed and released by its original Collection maintainer. This is a potential security issue and breaks the supply chain from creator to consumer.

Providing security-focused features in Ansible Automation Platform 2 continues to be a priority, to enable the execution of certified and supported automation anywhere in your hybrid cloud environment. New in Ansible Automation Platform 2.2  is Continue reading

New reference architecture: Red Hat Ansible Automation Platform 1.2 to 2 Migration Guide

 

Side-by-Side migration to Ansible Automation Platform 2

 

The release of Red Hat Ansible Automation Platform 2.1 comes with a re-imagined architecture that delivers exciting features such as automation mesh and automation execution environments among an entire suite of tools and components that enable enterprises to scale automation across their organizations.

With the importance of enterprise automation and taking advantage of the latest Ansible Automation Platform, we created a simple reference architecture to help guide you migrate from Ansible Automation Platform 1.2 to Ansible Automation Platform 2.

It consists of using a side-by-side methodology for the migration process via using the Ansible Automation Platform installer to do the migration and restoring a Database backup from a Ansible Automation Platform 1.2 cluster.  

 

Why are you going to love it?


Say goodbye to the guessing game of how you’ll migrate to the latest and greatest. Our goal is to simplify the migration planning, considerations and, most importantly, the step-by-step on how to do it. 

 

What will I find inside this reference architecture?

Inside this reference architecture you’ll find:

  • Migration considerations
  • Prerequisites
  • Infrastructure migration
  • Migrating virtual environments to automation execution environments

The migration considerations focus Continue reading

Migrating from Python virtual environments to automation execution environments in Ansible Automation Platform 2

Red Hat Ansible Tower (included in Ansible Automation Platform 1.x) used Python virtual environments to manage dependencies and implement consistent automation execution across multiple Red Hat Ansible Automation Platform instances. This method of managing dependencies came with its own set of limitations:

  • Managing Python virtual environments across multiple Ansible Tower instances. 
  • Confirming custom dependencies across Ansible Tower instances grew in complexity as more end-users interacted with it.
  • Python virtual environments were tightly coupled to the control plane, resulting in Operations teams bearing the majority of the burden to maintain them.
  • There were no tools supported and maintained by Red Hat to manage custom dependencies across Ansible Automation Platform deployments.

Ansible Automation Platform 2 introduced automation execution environments. These are container images in which all automation is packaged and run, which includes components such as Ansible Core, Ansible Content Collections, a version of Python, Red Hat Enterprise Linux UBI 8, and any additional package dependencies.

 

Why should you upgrade?

Ansible Automation Platform 2, announced at AnsibleFest 2021, comes with a re-imagined architecture that fully decouples the automation control plane and execution plane. The new capabilities enable easier to scale automation across the globe and allow Continue reading

What’s new in Ansible Automation Platform 2: automation execution environments

aap 2 gray flying as-1

Red Hat Ansible Automation Platform 2 is now available to customers. This release expands the possibilities of automation across your organization, with a more secure, flexible foundation to build and deploy automation with greater acceleration, orchestration and innovation.

As automation usage/practices/etc. spreads throughout an organization, managing multiple automation environments for different teams and use cases become 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 Ansible Automation Platform 2:

  • Enables the Ansible Automation Platform administrator with the ability to provide and manage automation execution environments (see below) to differing groups, like networking and cloud teams. Each has specific content needs for their roles  instead of addressing different environments as an 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.

  • Build and distribute automation execution environments via private automation hub, Continue reading

Introduction to ansible-test

As automation becomes crucial for more and more business cases, there is an increased need to test the automation code itself. This is where ansible-test comes in: developers who want to test their Ansible Content Collections for sanity, unit and integration tests can use  ansible-test  to achieve testing workflows that integrate with source code repositories.

Both ansible-core and ansible-base come packaged with a cli tool called ansible-test, which can be used by collection developers to test their Collection and its content. The ansible-test knows how to perform a wide variety of testing-related tasks, from linting module documentation and code to running unit and integration tests.

We will cover different features of ansible-test in brief below.

 

How to run ansible-test?

With the general availability of Ansible Content Collections with Ansible-2.9, a user can run ansible-test inside a collection to test the collection itself. ansible-test needs to be run from the collection root or below in order for ansible-test to run tests on the Collection.

If you try to run ansible-test from outside the above directory norms, it will throw an error like below:

[email protected] ~/.ansible/collections ansible-test sanity
ERROR: The current working directory must be at or below:
                                                                                                                                                                                                                                            
 Continue reading

Introduction to ansible-test

As automation becomes crucial for more and more business cases, there is an increased need to test the automation code itself. This is where ansible-test comes in: developers who want to test their Ansible Content Collections for sanity, unit and integration tests can use  ansible-test  to achieve testing workflows that integrate with source code repositories.

Both ansible-core and ansible-base come packaged with a cli tool called ansible-test, which can be used by collection developers to test their Collection and its content. The ansible-test knows how to perform a wide variety of testing-related tasks, from linting module documentation and code to running unit and integration tests.

We will cover different features of ansible-test in brief below.

How to run ansible-test?

With the general availability of Ansible Content Collections with Ansible-2.9, a user can run ansible-test inside a collection to test the collection itself. ansible-test needs to be run from the collection root or below in order for ansible-test to run tests on the Collection.

If you try to run ansible-test from outside the above directory norms, it will throw an error like below:

[email protected] ~/.ansible/collections ansible-test sanity
ERROR: The current working directory must be at or below:
                                                                                                                                                                                                                                            
-  Continue reading