When you try to build an ansible execution environment, you may need to use a container repository with a self-signed certificate.
This will fail with the following error;
.....
ERROR! Unknown error when attempting to call Galaxy at 'https://<URL>/api': <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)>
Error: error building at STEP "RUN ANSIBLE_GALAXY_DISABLE_GPG_VERIFY=1 ansible-galaxy collection install $ANSIBLE_GALAXY_CLI_COLLECTION_OPTS -r requirements.yml --collections-path "/usr/share/ansible/collections"": error while running runtime: exit status 1
This can be resolved by adding “ANSIBLE_GALAXY_CLI_COLLECTION_OPTS : “–ignore-certs” “
Based on previous posts, you probably have created an ansible execution environment.
After you have created an execution environment, how do you test it?
The new ansible CLI tool to run an ansible playbook is called “ansible-navigator”. It’s not only a ansible-playbook execution binary, but it has more features to it such as:
Review and explore available collections
Review and explore current Ansible configuration
Review and explore Ansible documentation
Review execution environment images available locally
Review and explore an inventory
Run and explore a playbook
But for the testing, this is what you need to do to test the newly created execution environment.
$ ansible-navigator run -eei localhost/<newly created EE name> --pp never <test ansible playbook>.yml
From above, the important option is “–pp never” which stands for “pull policy” “never”. This means that, since it’s already on the localhost, please don’t download the image. If for some reason, you forget the option, you will see the following error;
Trying to pull localhost/<new ee name>:latest...
WARN[0000] failed, retrying in 1s ... (1/3). Error: initializing source docker://localhost/<new ee name>:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp 127.0.0.1:443: connect: connection refused
WARN[0001] failed, retrying in 1s ... (2/3). Error: initializing source docker://localhost/<new ee name>:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp 127.0.0.1:443: connect: connection refused
WARN[0002] failed, retrying in 1s ... (3/3). Error: initializing source docker://localhost/<new ee name>:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp 127.0.0.1:443: connect: connection refused
Error: initializing source docker://localhost/<new ee name>:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp 127.0.0.1:443: connect: connection refused
[ERROR]: Execution environment pull failed
Also, the ansible-navigator’s default UI mode is “TUI” mode rather than printing out errors to stdout. If you would like to run ansible-navigator in stdout mode, just add an option;
$ ansible-navigator run --eei localhost/<newly created ee> --pp never <test ansible>.yml --mode stdout
With Red Hat’s Ansible Automation Platform 2.x, one of the big change is the introduction of Ansible Execution Environment.
Then questions rise; * What is an Ansible Execution Environment? * What is it for?
What is an Ansible Automation Execution Environment?
Below is a simple diagram summarising what it is.
High level overview of Automation Execution Environment
It is an optimised container environment that contains required “binaries”, “python+other Libraries” and ansible collections to execute an Ansible playbook(s).
Business/Technical Problems to solve: – To Provide a simplified & consistent execution environment to enhance automation development experiences
When a developer/user develops automation on their own environment and shares their own ansible playbooks with other team members, depending on their own development environment vs others, the automation experience could be very different. (Developing Ansible playbooks in a Mac vs Linux)
By creating and using the Ansible Automation Execution Environment, it provides the same development/execution experience.
– Multiple python environments to manage that creates maintenance overhead.
One of the main struggles was that Ansible Tower users had requirements for multiple python virtual environments as the number of users or number of use cases increased. E.g. for use cases, requirements of python 2.7 vs python 3.x or some modules requiring specific versions of python modules.
Above has resulted, within Ansible tower creating multiple python virtual environments, and if you have a cluster of ansible tower nodes, the administrator had to ensure all tower nodes have exactly the same python virtual environment configurations.
With a colleague of mine, we were testing migration of a ServiceNow – system provisioning ansible workflow from Ansible 2.9 -> Ansible Automation platform 2.x and hit an issue.
No such file or directory: '/usr/share/zoneinfo/zone.tab
My immediate thought would be that “tzdata” pkg is not installed on the UBI.
So added “tzdata” into bindep.txt and rebuild the EE image, but it didn’t work with error saying that nothing to install. (i.e. its already installed, just the file is not available, tested this with “append” in execution-environment.yml
[3/3] STEP 6/6: RUN ls -la /usr/share/zoneinfo/zone.tab
ls: cannot access '/usr/share/zoneinfo/zone.tab': No such file or directory
Error: error building at STEP "RUN ls -la /usr/share/zoneinfo/zone.tab": error while running runtime: exit status 2
To get rid of this issue, I had to just use append to “reinstall” using microdnf tzdata as below;
$ cat execution-environment.yml
---
version: 1
dependencies:
galaxy: requirements.yml
system: bindep.txt
additional_build_steps:
prepend:
append:
- RUN microdnf reinstall -y tzdata
- RUN ls -la /usr/share/zoneinfo/zone.tab
So what it is that… When you are writing a playbook and testing it, you need the following components:
Ansible IDE tool – my current favourite is VSCode, because there are so many nice extensions + Red Hat recently have released ansible extension
VSCode Ansible extension
Ansible-Core – the command line tool, the language and framework that makes up the foundational content before you bring in your customized content.
Ansible-Builder – to build execution environments
Ansible-navigator – to run, test playbooks with execution environments
If you haven’t built an execution environment, the very first thing that you need to do is to build an execution environment, as below:
4 files that you need to create are;
bindep.txt – Bindep is a tool for checking the presence of binary packages needed to use an application / library, so whatever is defined in this file will be installed.
requirement.txt – The python entry points to a Python requirements file for pip install -r …
requirement.yml – Outlines ansible collection requirements for galaxy to download and include into the execution environment.
execution-environment.yml – A definition file as an input and then outputs the build context necessary for creating an Execution Environment image
Once the required execution environment is ready, it can be shared across your colleagues to enhance the collaboration experiences through consistencies.
Also, now you can start to develop an ansible playbook;
Finally, once you are happy with the playbook and the execution environment, it should be uploaded and managed in source management systems:
playbooks – Source Control Management Systems – e.g. github, gitlab….
EE image – e.g.) Automation hub, Quay.io, artifactory…
Then those can be properly leveraged by Ansible Automation Platform.
So in the previous series of articles, I have discussed what Ansible Execution Environment (EE) is, and how it is being consumed in the Automation Controller.
But really, how can I tell whether it is being ran or not?
Simple! This can be validated by running “watch podman ps” on (a) execution node(s).
Below are 3 screenshots from moments of “before”, “during”, “after” a sample automation execution.
Command to run:
# su - awx
# watch podman ps
Before:
Before the automation execution
During:
During the automation execution
After:
After the automation execution
As you can see from the above, execution environment is dynamically spun up as a container and cleaned up right after the execution is completed.