Today is just for me to add a link for me to remember.
Below is a great summary of the issue and how it can be resolved when you try to build an ansible execution environment in a disconnected environment.
https://cloudautomation.pharriso.co.uk/post/ansible-builder-disconnected/
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 1This can be resolved by adding “ANSIBLE_GALAXY_CLI_COLLECTION_OPTS : “–ignore-certs” “
[svc_aap_install@AGAEALP3001264 ee-infoblox-build]$ cat execution-environment.yml
---
version: 1
build_arg_defaults:
EE_BUILDER_IMAGE: '<URL>/ansible-builder-rhel8'
EE_BASE_IMAGE: '<URL>/ee-supported-rhel8'
ANSIBLE_GALAXY_CLI_COLLECTION_OPTS : "--ignore-certs"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.
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 2To 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
[3/3] STEP 6/7: RUN microdnf reinstall -y tzdata
Downloading metadata...
Downloading metadata...
Downloading metadata...
Downloading metadata...
Downloading metadata...
Package Repository Size
Reinstalling:
tzdata-2021e-1.el8.noarch ubi-8-baseos 485.0 kB
replacing tzdata-2021e-1.el8.noarch
Transaction Summary:
Installing: 0 packages
Reinstalling: 1 packages
Upgrading: 0 packages
Obsoleting: 0 packages
Removing: 0 packages
Downgrading: 0 packages
Downloading packages...
Running transaction test...
Reinstalling: tzdata;2021e-1.el8;noarch;ubi-8-baseos
Complete.
--> 0a9e9e0a1ed
[3/3] STEP 7/7: RUN ls -la /usr/share/zoneinfo/zone.tab
-rw-r--r--. 1 root root 19419 Sep 20 16:34 /usr/share/zoneinfo/zone.tab
[3/3] COMMIT servicenow-ee-29For a customer recently, I had to talk about with Ansible Automation 2.x, what is required to develop ansible playbooks.
Here is a high-level workflow diagram that I drew;
So what it is that… When you are writing a playbook and testing it, you need the following components:
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;
Detailed examples can be found in:
https://www.ansible.com/blog/introduction-to-ansible-builder
https://ansible-builder.readthedocs.io/en/latest/
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:
Then those can be properly leveraged by Ansible Automation Platform.
Last week finally, AAP 2.1 was released.
Here is the release note: https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.1/html/red_hat_ansible_automation_platform_release_notes/index
Here is a blog post from Red Hat: https://www.ansible.com/blog/introducing-red-hat-ansible-automation-platform-2.1
So to recap some of highlights are;
Automation Mesh:
This is the newest addition to Ansible Automation Platform, and replaces the isolated nodes feature in 1.2. By combining automation execution environments in version 2.0 with automation mesh in version 2.1, the automation control plane and execution plane are fully decoupled, making it easier to scale automation across the globe. You can now run your automation as close to the source as possible, without being bound to running automation in a single data center. With automation mesh, you can create execution nodes right next to the source (for example, a branch office in Johannesburg, South Africa) while execution is deployed on our automation controller in Durham, NC.
Automation mesh adds:
With Red Hat’s new Ansible Automation Platform 2.
Now you have to create an execution environment for you to run your automation.
If you are interested in knowing more about what’s Ansible Execution Environment? and how to build the execution environment please read more on;
To get into the topic now.
With the new Ansible Private Automation, Red Hat has incorporated a “container registry” into the Ansible Private Automation hub.
So how do we upload the execution environment that you built locally using “ansible-builder”?
Make sure you have your locally built image ready.
For this example, the image name is “my_first_ee_image“
(builder) # podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/my_first_ee_image latest 18ee9d1f8d86 2 weeks ago 747 MB
<none> <none> f64cafba5f7b 2 weeks ago 740 MB
<none> <none> 2ee39fed1806 2 weeks ago 747 MB
<none> <none> 36ea822bf2b4 2 weeks ago 740 MB
quay.io/ansible/ansible-runner latest a24b29574c26 2 weeks ago 725 MB
<none> <none> d5790b11bfe2 2 weeks ago 747 MB
<none> <none> 20839e67474e 2 weeks ago 647 MB
(builder) # podman login -u=admin https://<FQDN or IP>/ --tls-verify=0
Password:
Login Succeeded!
Because, I am currently running my Private Automation Hub locally, I had to add “–tls-verify=0” or “–tls-verify=false” option.
(builder) # podman tag localhost/my_first_ee_image <FQDN/IP>/my_first_ee_image
(builder) # podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/my_first_ee_image latest 18ee9d1f8d86 2 weeks ago 747 MB
<IP/FQDN>/my_first_ee_image latest 18ee9d1f8d86 2 weeks ago 747 MB
<none> <none> f64cafba5f7b 2 weeks ago 740 MB
<none> <none> 2ee39fed1806 2 weeks ago 747 MB
<none> <none> 36ea822bf2b4 2 weeks ago 740 MB
The format is that;
# podman push <Image ID> <URL>/<Image name>:<tag>
(builder) # podman push --tls-verify=false 18ee9d1f8d86 <FQDN/IP>/my_first_ee_image:latest
Getting image source signatures
Copying blob 32e86e0f9e53 done
Copying blob f47aeb60ec80 done
Copying blob c6ecf1ab50fb done
Copying blob ba176c23a887 done
Copying blob bb33f1f5d1b5 done
Copying blob f481c8dd5cb9 done
Copying blob 1ad9df8c4500 done
Copying blob 205c0028fa95 done
Copying blob 21adbb7c8fd5 done
Copying blob 3f69621a2c45 done
Copying blob b121b5075674 done
Copying blob 50de17c442cc done
Copying blob 39ac6dd69b36 done
Copying blob 9c229aeded24 done
Copying blob 2653d992f4ef done
Copying blob 48c89702f240 done
Copying blob 07805e10d0e1 done
Copying blob 5f70bf18a086 done
Copying blob 58e24711c0de done
Copying config 18ee9d1f8d done
Writing manifest to image destination
Storing signatures
Now, this image can be used in Ansible Automation Platform 2.x, as a preview;
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:
During:
After:
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.
Ansible Core is the command-line tool that is installed from either community repositories or the official Red Hat repositories for Ansible.
https://www.redhat.com/en/blog/ansible-101-ansible-beginners
With Ansible Automation Platform 2 release, few terminology changes were made.
One of those are, Ansible Engine as we know which included ansible binaries, modules are replaced with “Ansible-Core”.
Ansible Core is the foundational part of the Ansible Automation Platform. It’s the command line tool, the language and framework that makes up the foundational content before you bring in your customized content.
The main differences between ansible-engine and ansible-core are “contents” e.g. modules and plugins.
Ansible Core only comes with limited number of contents.
(Number of ansible modules comparison between ansible 2.9 vs 2.11 can be found here.)
By moving contents out of the ansible-core, this provides following benefits:
As you can guess, this change was another foundation for Ansible Automation Execution Environment a.k.a ansible EE.
From, Red Hat’s Ansible Automation platform 2, one of the big changes is that the “ansible engine” is now changed to the “ansible core”.
With the change, the biggest change is that number of ansible modules that were shipped with ansible has dropped significantly.
This change was made to decouple ansible binary with modules.
Ansible modules development is mainly driven by;
This decoupling would provide shorter and community-driven release schedules, which usually doesn’t sync with actual ansible binary release.
More details Ansible Core change details can be found in HERE.
N.B. This is based on my current test environments, where I have ansible 2.9.22 and 2.11.1. Also two environments’ installation methods are different.
2.9.22 – RPM -> 3232 modules
2.11.1 – venv/pip -> 71 modules
2.12.0-2 – RPM -> 70 modules
ansible 2.9.22
[root@insights-client2 modules]# rpm -qa |grep ansible
ansible-2.9.22-1.el7ae.noarch
[root@insights-client2 modules]# pwd
/usr/lib/python2.7/site-packages/ansible/modules
[root@insights-client2 modules]# ls -lR |grep ".py" | awk '{print $9}' |grep -v ^_ |grep -v "pyc" |grep -v "pyo" |wc -l
3232
ansible 2.11.1
(py36-venv) [djoo@insights-client2 modules]$ ansible --version
[DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the controller starting with Ansible 2.12. Current version: 3.6.12
(default, Sep 15 2020, 12:49:50) [GCC 4.8.5 20150623 (Red Hat 4.8.5-37)]. This feature will be removed from ansible-core in version 2.12.
Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
ansible [core 2.11.1]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/djoo/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/djoo/py36-venv/lib64/python3.6/site-packages/ansible
ansible collection location = /home/djoo/.ansible/collections:/usr/share/ansible/collections
executable location = /home/djoo/py36-venv/bin/ansible
python version = 3.6.12 (default, Sep 15 2020, 12:49:50) [GCC 4.8.5 20150623 (Red Hat 4.8.5-37)]
jinja version = 3.0.1
libyaml = True
(py36-venv) [djoo@insights-client2 modules]$ pwd
/home/djoo/py36-venv/lib/python3.6/site-packages/ansible/modules
(py36-venv) [djoo@insights-client2 modules]$ ls -lR |grep ".py" | awk '{print $9}' |grep -v ^_ |grep -v "pyc" |grep -v "pyo" |wc -l
71
ansible 2.12.0.2
[root@ip-172-31-14-126 modules]# rpm -qa |grep ansible-core
ansible-core-2.12.0-2.el8ap.x86_64
[root@ip-172-31-14-126 modules]# pwd
/usr/lib/python3.8/site-packages/ansible/modules
[root@ip-172-31-14-126 modules]# ls -lR |grep ".py" | awk '{print $9}' |grep -v ^_ |grep -v "pyc" |grep -v "pyo" |wc -l
70
djoo's World 