Streamlining Automation: Exploring Ansible Execution Environments for Efficient Configuration Management

Getting started with Execution Environments

Execution Environments (EEs) are Ansible control nodes packaged as container images. EEs remove complexity to scale out automation projects and make things like deployment operations much more straightforward.

Ansible execution environments (EE) were introduced in Ansible Automation Platform 2 to provide a defined, consistent and portable environment for executing automation jobs. Execution environments are basically Linux container images that help execute Ansible playbooks.

So lets start using the ansible’s execution environment. We will have to setup the controller node. Here i am using aws ec2 instances for controller node and target node. I am using redhat 9 os image.

Now we have to install the ansible inside the controller node. Here’s the ansible’s software name ansible-core. In redhat below version 9 the software name was ansible. You can use below commands to install ansible-core software.

# Installing ansible software
yum install ansible-core

The above image have ansible.cfg, ansible-key.pem, ansible-navigator.yml, inventory and web.yml file. Let’s start creating these files in the below steps.

1. ansible.cfg — The ansible.cfg file is a configuration file used to customize Ansible's behavior. It allows users to define settings such as default paths, connection types, verbosity levels, and more.
   
   Now let’s configure the ansible.cfg file. In this file in the default section you have to add the location of the inventory file, the remote user (if using ubuntu/centos use ubuntu/centos as a user) as here i am using ec2 instance and ec2-user user respectively, private key attached to the ec2 instance and host_key_checking should be false.
   
   In the privilege_escalation section add the below content to enable the sudo power on the target node.

[defaults]
inventory = ./inventory
remote_user = ec2-user
private_key_file = ./ansible-key.pem
host_key_checking = False

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

2. ansible-key.pem — An EC2 instance PEM file, often referred to as a PEM key or PEM file, is a private key file used for SSH authentication when connecting to an Amazon Elastic Compute Cloud (EC2) instance. When you create a new EC2 instance, Amazon EC2 provides you with a key pair consisting of a public key and a private key.

3. inventory — The inventory file is a text file that lists the hosts (servers, network devices, etc.) that Ansible will manage. It serves as the primary source of information about the infrastructure that Ansible can interact with. The inventory file can also include additional information such as host variables, groupings of hosts, and variable assignments.
In the above image you see the target node ip address 43.205.117.222.

4. web.yaml — An Ansible playbook is a YAML file that defines a set of tasks to be executed on one or more remote hosts. Playbooks are the primary means of automation in Ansible and allow users to define the desired state of the systems they manage. Below is the content of ansible playbook which does installation for httpd (apache webserver).

# The ansible playbook contains below content
- hosts: all
  tasks: 
    - name: "Installing web packages"
      package: 
         name: "httpd"
         state: present

5. ansible-navigator.yml — You can create a configuration file to customize various aspects of ansible-navigator. The default location for this file is ~/.ansible-navigator.yaml.

Pre-requisite of using navigator — If you are using ansible navigator feature then you have to install ansible navigator from python pip3 and podman from yum binary. You can use the below commands to install the ansible-navigator binary and podman.

# Installing python pip3 and ansible navigator binary

yum install python3-pip 
pip3 install ansible-navigator

# Installing podman
yum install podman

You have to use the below command to create a ansible-navigator.yml file. This file comes with lots of contents. Here you can replace below content in the ansible-navigator.yml file.

ansible-navigator settings --sample > ansible-navigator.yml

In the below yml file, The path of the ansible configuration file is ./ansible.cfg, the inventory file path is ./inventory, the path of playbook is ./web.yml. The execution-engine is podman, As we are using podman as a container engine so we have to enable it(by default it’s already enabled). The image creator — — ee:v0.22.0 is the default image provided by ansible-core. The image pull policy is never i.e every time you run the playbook it won’t download the image.

---
ansible-navigator:
   ansible:
     config:
       path: ./ansible.cfg
     inventory:
       entries:
         - ./inventory
     playbook:
       path: ./web.yml
   execution-environment:
     container-engine: podman
     enabled: True
     image: creator-ee:v0.22.0 
     pull:
       policy: never

If you are not using ansible navigator feature provided by ansible, then the controller node will use its own base os python, jinja libraries and ansible modules. But if you are using ansible’s navigator feature then it will use the podman enviromnent to execute the playbook.

When you using container engine as podman/docker and run the playbook then ansible creates a container in the background and it will run the playbook in that respective container and after the playbook executes successfully it will removes the container.

Now when you hit the ansible-navigator run command it will start creating the podman container as a execution environment. In this execution environment ansible will be running the playbook. All the ansible modules and python, jinja libraries will be used from the container itself. The playbook, roles, collections will also be copied to the container automatically.

running ansible navigator command

Here in the changed object is 1, that is installing the httpd (apache webserver). Below you can see the output.

ansible navigator run

apache webserver installed

In conclusion, Ansible Execution Environments represent a significant step forward in the management and deployment of automation workflows. By encapsulating dependencies within isolated environments, they provide greater consistency and reproducibility across different infrastructure setups. This not only enhances reliability but also simplifies collaboration and deployment processes within teams.

Furthermore, the flexibility offered by Execution Environments empowers users to tailor their automation environments to specific project requirements, ensuring compatibility with different Ansible versions and module dependencies. This flexibility extends to the integration of custom modules and plugins, facilitating the development of tailored solutions for diverse use cases.

As organizations increasingly adopt Ansible for managing complex IT infrastructures, the adoption of Execution Environments is poised to become a standard practice. Their ability to streamline development workflows, enhance stability, and simplify deployment processes makes them a valuable addition to the Ansible ecosystem.

In essence, Ansible Execution Environments pave the way for more efficient automation practices, enabling teams to focus on innovation and value creation rather than grappling with infrastructure complexities. As this technology continues to evolve, it promises to further revolutionize the way organizations manage and deploy automation at scale.