Execution Environments

We have seen how Ansible Automation Controller enables you to scale your automation by leveraging an easy-to-use web interface, RBAC, and logging to allow other people to use the automation in a way that conforms to your company’s rules.

In this chapter, we will discuss execution environments, a feature of Ansible that was released a few years ago, but it is critical to create automation that lasts. More specifically, we’re going to cover the following main topics:

• The importance of execution environments
• Building an execution environment
• Running playbooks in an execution environment
• Uploading execution environments to a container registry
• Using execution environments in the automation controller

Technical requirements

To follow this chapter’s examples, you will need ansible-builder version 3.0 or later.

Ansible Builder requires Python 3.8 or higher, which you probably have already installed on your system.

The easiest way to install ansible-builder is to use PyPi:

$ pip install ansible-builder

The importance of execution environments

The first question you might have is, why do we need an execution environment in the first place?

There are three reasons why execution environments can simplify your life:

• They allow better scalability by being distributed to multiple machines
• They allow you to freeze all dependencies to specific versions so that you can run the same playbook in five years, with the certainty that it will run exactly as you expect
• They allow you to use different ones for different playbooks so that you can decide when to upgrade each playbook runtime, independently from the others

So, how do execution environments achieve all this? They do so by leveraging containers. In fact, execution environments are containers that contain at least the Ansible runner and the required libraries to run. In addition, execution environments might also include an Ansible collection and many other components that are needed to run your automation.

...

Building an execution environment

To create an execution environment, we will need a definition file. There are three versions of the definition file, and based on the version of ansible-builder, some versions might not be available to you. Let’s be more specific:

• Version 1: Supported by all ansible-builder versions
• Version 2: Supported by ansible-builder versions 1.2 and higher
• Version 3: Supported by ansible-builder versions 3.0 and higher

Since version 3 of the definition is the easiest to learn and use, all examples will use this version.

We will start with a minimal example and then build on it.

Creating a minimal execution environment

To create an execution environment, we need to create a YAML file. By default, ansible-builder will be looking for the file named execution-environment.yml. Although different names can be used and ansible-builder can be informed using the -f FILENAME flag, we will stick with the default name in this book.

...

Running playbooks in an execution environment

Now that we have explored how to create execution environments, we can start using them. The first thing we will do is check the Ansible and Python versions.

To execute commands and Playbooks in execution environments, we can use ansible-navigator. To install it, we can execute $ pip install ansible-navigator.

The equivalent of the ansible --version command in the minimal-ee is the following:

$ ansible-navigator exec --eei minimal-ee -- ansible --version

As you can see, the biggest difference is the addition of --eei minimal-ee, which tells ansible-navigator which execution environment image to use, and running it will return the following:

ansible [core 2.15.1]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/tmp/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.9/site-packages...

Uploading execution environments to a container registry

As discussed, execution environments are packaged in the container image format to allow more flexibility. This means that we can upload an execution environment to any container registry. In enterprise settings, Ansible Automation Hub is usually used, since it is a tool very similar to Ansible Galaxy that can be installed in the private company network, and it hosts Ansible collections and execution environments. Companies often prefer Ansible Automation Hub, since it integrates a lot of nice features, such as synchronization with Ansible Galaxy. If you have an Ansible Automation Hub available, you can use it to follow the following steps. Otherwise, you can use any other container registry.

I will use quay.io, but the same steps apply to any other container registry.

Ensure your Podman is properly logged into your container registry of choice. You can use podman login to perform the login if you are not logged in yet...

Using execution environments in Ansible Automation Controller

Using Ansible execution environments in Ansible Automation Controller is very straightforward, since it always uses an execution environment while executing Playbooks. The only difference is whether it is the default execution environment or the one that you built and specified.

The first thing we will need to do is add a new execution environment to Ansible Automation Controller or AWX. To do so, you need to go to execution environments in the navigation bar in the Administration section, and then click on the Add button. You can now fill in the name and the image URL and select Always pull container before running. as the Pull option, as follows:

Figure 14.1 – Creating a new execution environment window

After saving the execution environment by pressing Save, you can go to Templates in the navigation bar under Resources and create a new job template, or modify the one you already...

Summary

We started this chapter by seeing why execution environments can help you to create a more resilient automation solution in your environment. We then moved on to a more practical section in which you created multiple execution environments, firstly a minimal one, then one with a customized version of Python, and finally, one with some collections and other dependencies embedded. We then used those execution environments locally using ansible-navigator. We then uploaded them to a container registry and used them from Ansible Automation Controller or AWX.

We have now reached the end of this book, since this is the last chapter, and I would like to thank you for reading the entire book. I hope that it has taught you what you initially hoped to learn about Ansible, and more!

Questions

1. Ansible uses the standard container image format for execution environments:
   1. True
   2. False
2. Which of the following is an advantage of Ansible execution environments?
   1. They run Ansible playbooks without Ansible
   2. They guarantee the exact versions of Ansible, the dependencies, and the collections on every run
   3. They increase performance
3. What is the latest execution environment definition version?
   1. 1
   2. 2
   3. 3
   4. 4

Further reading

• Ansible Builder documentation: https://ansible.readthedocs.io/projects/builder/en/stable/usage/
• Ansible Navigator documentation: https://ansible.readthedocs.io/projects/navigator/
• Execution environment version 3 specification: https://ansible.readthedocs.io/projects/builder/en/stable/definition/#version-3-format