Execution environments are Linux container images which are built on top of the Red Hat Universal Base Images (UBI) and additionally contain:
This makes the execution of an ansible playbook more scalable, reliable and predictable since the combination of Playbook and execution environment should always deliver the same results.
ansible-builder in your lab environment: on RHEL this is provided by the AAP repo, on Fedora you will need
pip install ansible-builder, it’s recommended to use a virtual environment in this case.
ansible-builder is a high-level tool for building AAP Execution Environments that abstracts away a lot of the intricacies of container image building. Under the hood it uses
podman, of course.
# Only if you're not on RHEL dnf -y install python3-virtualenv virtualenv ansible-builder . ansible-builder/bin/activate pip install -U pip ansible-builder # If you are on RHEL and the AAP repo is enabled sudo yum install ansible-builder
In the previous chapter you have learned how you can still use collections not contained in an Execution Environment in a Playbook. But in many cases you’ll start building custom EE’s at some point containing collections you use frequently in your Ansible content.
In this chapter you’ll do exactly this: build a custom Execution Environment.
We have prepared a repository with the needed content to build the EE image. Go and clone the repo to your VS Code terminal:
git clone https://github.com/ansible-learnfest/ee-flow.git
As the base image will be pulled from the Red hat container registry, you have to login with your personal Red Hat login credentials (the one you use on access.redhat.com) in the VS Code terminal:
podman login registry.redhat.io
bindep.txtlists rpm that need to be installed into the EE
requirements.txtis for installing additional Python dependencies
requirements.ymlmight be the most important by listing the Collections which should go into the EE.
The three files describing the content and possible additional build steps are pulled together in a
.yml build file,
ee-ansible-demo.yml in our case. Again feel free to examine the file.
containers.podmancollection in the EE, change the
requirements.ymlto include it (hint: use the content of the file you uploaded to PAH in the previous chapter).
ansible-builderto create the new EE as in the example below (make sure you are in
ansible-builder build -f ee-ansible-demo.yml -t ee-ansible-demo:0.1.0 -v 3
We’re using the
-v 3 flags to get more detailed output from
ansible-builder - by default the tool is very quiet. Also note how we give a name to the image together with a tag.
podman is used to actually build the image, the
Containerfile needed by Podman is created by
ansible-builder. Please take the time to locate it and have a look at it.
Before we push a custom EE to a registry and use it in Automation Controller we want to make sure it provides what we need to run our Playbooks with all dependencies. Basically check if it works… :-)
For this we run a Playbook in the runtime environment the EE provides. Because
ansible-playbook can’t do this, we need to use the second new tool on the block,
ansible-navigatorto use the previously created EE either by
Specify the name of the execution environment imagein the output of
~/.ansible-navigator.yamldot-file and add this content:
--- ansible-navigator: execution-environment: image: ee-ansible-demo:0.1.0
ansible-navigatorand start to explore its features. Navigating is straight forward, first check the
ee-ansible-demoEE contains the
:collectionson the start page.
ESCalways takes you back one step in the menu structure.
Then have a look at the included EE images:
:images, choose an image by typing the row number
ESCis your friend when you got lost in menus items…
Now we finally want to run a Playbook to test the new EE. The demo Playbook you used before in Automation Controller is part of the GitHub repo
ee-flow you checked out already. So we just need an inventory to go with it.
cp /etc/ansible/hosts lab_inventory.ini
~/ee-flow/ansible-builder/lab_inventory.iniand remove or comment out all nodes except ’node2’. The result should look something like this (note all other lines are removed!):
[managed_nodes] #node1.<LABID>.internal node2.<LABID>.internal #node3.<LABID>.internal
ansible-navigatorand run the Playbook:
:run ~/ee-flow/deploy-container.yml -i ~/ee-flow/ansible-builder/lab_inventory.ini
deploy httpd container, this will bring you to the task list from where you can inspect the running tasks.
There is a command line parameter to
ansible-navigator that makes the run and output mimic
ansible-playbook, that is not jumping into the TUI interface, give it a try:
ansible-navigator run ~/ee-flow/deploy-container.yml -i ~/ee-flow/ansible-builder/lab_inventory.ini -m stdout
ansible-navigatorto inspect and run a Playbook in a custom EE.