In the ever-evolving landscape of IT and DevOps, automation plays a pivotal role in streamlining workflows and ensuring efficiency. Ansible, a powerful open-source automation tool at the heart of this transformation, simplifies complex tasks through declarative configuration files.
Ansible Automation Platform (AAP): A Comprehensive Solution
Ansible Automation Platform (AAP) takes the capabilities of Ansible to the next level, offering a comprehensive suite of tools to manage and scale automation across the enterprise. At its core are Ansible Tower and its open-source counterpart, AWX.
AWX: Unleashing the Power of Open-Source Automation
AWX serves as the upstream project for Ansible Tower, providing a feature-rich, open-source platform for managing Ansible playbooks, inventories, and tasks. With an intuitive web-based interface, AWX empowers users with job scheduling, role-based access control (RBAC), and real-time insights into automation workflows.
Now, as organizations embrace the flexibility of containerization and Kubernetes, AWX has evolved to provide even more agility through the concept of “execution environments.
Execution Environments in AWX: A Paradigm Shift
Execution environments in AWX represent a paradigm shift in how Ansible tasks are executed. Each job triggers the creation of a containerized environment, ensuring isolation, reproducibility, and scalability. This innovation enhances the reliability of automation and opens the door for customization to meet specific workflow requirements.
Customizing Execution Environments with Ansible Builder: Tailoring Your Automation Stack
Ansible Builder is a tool that allows users to design and build customized execution environments tailored to their specific needs. This blog will guide you through customizing Ansible execution environments using AWX, from choosing the right base image to defining Python versions, Ansible cores, collections, and more.
Join us on a journey to unlock the full potential of your automation workflows. Whether you are a seasoned Ansible user or just getting started with AWX and AAP, this blog will equip you with the knowledge to elevate your automation game through customized execution environments. Let’s dive in!
Before diving into the customization of Ansible execution environments, you need to ensure that Ansible Builder is installed on your system.
[root@server1 ~]# pip3 install ansible-builderAfter installation, verify that the Ansible Builder is working correctly by running a basic command.
[root@server1 ~]# ansible-builder --version
3.0.0
[root@server1 ~]#After completing the installation of Ansible Builder, we are ready to proceed with the initial configuration steps. These steps will involve setting up a dedicated project directory and creating an execution environment definition file, laying the foundation for customizing Ansible (AWX) execution environments based on your specific requirements.
[root@server1~]# mkdir custom-ee
[root@server1~]# cd custom-eeWithin this directory, we’ll organize our project by creating the following requirements files:
requirements.yml: This file is used for specifying Ansible collections information. Here, you can list the collections your project depends on.
[root@server1 custom-ee]# cat requirements.yml
---
collections:
- cisco.dnac
- community.vmware
- awx.awxrequirements.txt: In this file, you’ll define your Python packages and their versions. These packages will be essential for the functionality of your custom execution environment.
[root@server1 custom-ee]# cat requirements.txt
ansible==9.1.0
setuptools==67.7.2
GitPython==3.1.31
kubernetes==26.1.0
netaddr==0.8.0
psutil==5.9.5bindep.txt: Specify your system dependencies in this file. These dependencies ensure that your execution environment has all the necessary components to run successfully.
[root@server1 custom-ee]# cat bindep.txt
openssh-clients [platform:rpm]
sshpass [platform:rpm]
git [platform:rpm]execution-environment.yml: This YAML file is pivotal for defining the configuration of our Ansible execution environment. It serves as the blueprint for customizing the environment, allowing us to specify details such as the base container image, Python version, Ansible-core version, Ansible Runner version, and more.
[root@server1 custom-ee]# cat execution-environment.yml
---
version: 3
dependencies:
system: bindep.txt
galaxy: requirements.yml
python: requirements.txtThe execution-environment.yml file serves as a crucial input to Ansible Builder, guiding the creation of a customized image by specifying system dependencies, Ansible collections, and Python packages. This YAML file acts as a comprehensive configuration blueprint, allowing you to tailor your Ansible (AWX) execution environment based on specific project requirements.
The establishment of requirements.yml, requirements.txt, bindep.txt, and execution-environment.yml sets the stage for a structured and organized approach to managing Ansible execution environments. This approach not only streamlines customization but also facilitates seamless replication whenever needed.
By default, the execution-environment.yml file references the image quay.io/ansible/ansible-runner:latest, featuring CentOS 8 as the underlying operating system. However, if you wish to use a different image not provided by the Ansible community, you have the flexibility to specify your image in the execution-environment.yml file. This capability ensures that your Ansible execution environment aligns precisely with your unique project requirements, allowing for a truly customized and tailored experience.
To use a custom base image in your Ansible (AWX) execution environment, you can define it in the execution-environment.yml file. Here’s an example:
[root@server1 custom-ee]# cat execution-environment.yml
---
version: 3
images:
base_image:
name: quay.io/centos/centos:stream9
dependencies:
ansible_core:
package_pip: ansible-core
ansible_runner:
package_pip: ansible-runner
system: bindep.txt
galaxy: requirements.yml
python: requirements.txtIn this example, the images the section specifies a custom base image (quay.io/centos/centos:stream9). Additionally, the dependencies section outlines crucial components such as Ansible Core (ansible-core) and Ansible Runner (ansible-runner), which are essential for executing jobs on the custom image.
When using your image, it’s important to note that certain dependencies, such as Ansible Core and Ansible Runner, must be explicitly installed to enable job execution. By incorporating these details into your execution-environment.yml file, you gain the flexibility to define a tailored environment that aligns precisely with your project’s needs.
Now that we have configured our execution-environment.yml file with the desired specifications, we can use Ansible Builder to build our custom execution environment image.
[root@server1 custom-ee]# ansible-builder build --tag test:v1 --verbosity=3
Ansible Builder is generating your execution environment build context.
File context/_build/requirements.yml is already up-to-date.
File context/_build/requirements.txt is already up-to-date.
File context/_build/bindep.txt is already up-to-date.
File context/_build/scripts/assemble is already up-to-date.
File context/_build/scripts/install-from-bindep is already up-to-date.
File context/_build/scripts/introspect.py is already up-to-date.
File context/_build/scripts/check_galaxy is already up-to-date.
File context/_build/scripts/check_ansible is already up-to-date.
File context/_build/scripts/entrypoint is already up-to-date.
Ansible Builder is building your execution environment image. Tags: test:v1
Running command:
podman build -f context/Containerfile -t test:v1 context
time="2023-12-27T09:47:28+05:30" level=warning msg="missing \"EE_BASE_IMAGE\" build argument. Try adding \"--build-arg EE_BASE_IMAGE=<VALUE>\" to the command line"
time="2023-12-27T09:47:28+05:30" level=warning msg="missing \"PYCMD\" build argument. Try adding \"--build-arg PYCMD=<VALUE>\" to the command line"
time="2023-12-27T09:47:28+05:30" level=warning msg="missing \"PKGMGR_PRESERVE_CACHE\" build argument. Try adding \"--build-arg PKGMGR_PRESERVE_CACHE=<VALUE>\" to the command line"
time="2023-12-27T09:47:28+05:30" level=warning msg="missing \"ANSIBLE_GALAXY_CLI_COLLECTION_OPTS\" build argument. Try adding \"--build-arg ANSIBLE_GALAXY_CLI_COLLECTION_OPTS=<VALUE>\" to the command line"
time="2023-12-27T09:47:28+05:30" level=warning msg="missing \"ANSIBLE_GALAXY_CLI_ROLE_OPTS\" build argument. Try adding \"--build-arg ANSIBLE_GALAXY_CLI_ROLE_OPTS=<VALUE>\" to the command line"Executing this command triggers Ansible Builder to read the execution-environment.yml file, download the specified base image, install the required dependencies, and construct the final execution environment image tailored to your project’s needs.
Once the custom Ansible execution environment image is successfully created, the next step is to push it to an image registry accessible by Ansible (AWX). Execute the following command, replacing “test:v1” with your image tag:
[root@server1 custom-ee]# podman push test:v1Now we need to add a new Execution environment image on AWX. Log in to your AWX UI. Click on the “Execution Environments” option on the left-hand side of the AWX UI and Click on the “Add” button to create a new execution environment.
Enter the necessary details about your execution environment image, such as the name, image registry location, tag, and pull policy.
After saving the details, your custom execution environment will be listed on the Execution Environment page.
Now that the custom execution environment is added to AWX, you can associate it with your job template to utilize it in your automation workflows.
By following these steps, you’ve successfully integrated and made your custom Ansible execution environment available for use in AWX, enhancing the flexibility and customization of your automation processes.
Time to Revolutionize Your Automation Workflows!
You’ve just taken a significant step towards supercharging your Ansible automation workflows. By creating and customizing execution environments, you’ve unlocked a realm of possibilities to tailor automation to your project’s unique requirements.
Dive into your projects and start experimenting with custom execution environments. Tailor them to fit your specific needs and witness the impact on your automation tasks.
If you discover unique approaches, face interesting challenges, or have valuable insights to share, don’t hesitate to leave a comment below. Your experiences can enrich the community and inspire others on their automation journey.
Thank you for joining us on this journey. If you have any questions or insights to share, feel free to leave a comment below.
Wishing you a future filled with seamless, customized automation experiences. Happy automating!