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 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 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 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.
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
- RUN microdnf reinstall -y tzdata
- RUN ls -la /usr/share/zoneinfo/zone.tab
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:
Dynamic cluster capacity. You can increase the amount of execution capacity as you need it.
Global scalability. The execution plane is now resilient to network latency and connection interruptions and improves communications.
Secure automation. Bi-directional communication between execution nodes and control nodes that include full TLS authentication and end-to-end encryption.
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:
Agility – Currently ansible contents are being developed and managed by Open Source Communities, partners and Red Hat. Now modules can be updated and managed through developers-driven and ansible-independent schedules.
A lean & Purpose driven execution environment – By only incorporating required plugins and modules, it bring the focus back into the users’ automation environment, rather than overloading with unnecessary contents.
As you can guess, this change was another foundation for Ansible Automation Execution Environment a.k.a ansible EE.
The biggest announcement would be on the Ansible Automation Platform 2.
Last July, there was a sneak preview + early access program for Ansible Automation Platform 2.0. (Link)
N.B. This is an “early access” program, which means?
Early access means that any Red Hat Ansible Automation Platform subscriber has the ability to download, install, and file support cases against this newly released 2.0 version of the product. Because there are additional core features and functionality that are slated for the 2.1 release later this year, the formal marketing launch for both 2.0 and 2.1 versions will happen later this year at AnsibleFest. Therefore, many of the typical resources (such as documentation, blogs, etc.) will only be made available on the Red Hat Customer Portal until formal launch at AnsibleFest.
So with the release of Ansible Automation Platform 2.1 in later 2021, Ansible Automation Platform 2 will be properly GA’ed.
However, in this article, I am going to focus on three main announcements:
1. Ansible Tower and Ansible Engine are no more.
=> Its replaced with Red Hat Ansible Automation Platform.
More details to be followed below.
2. Ansible Core – “Batteries are not included”
Ansible engine is now replaced with a component from Red Hat Ansible Automation Platform called “ansible-core”
Different to the Ansible Engine, the “ansible-core” will only include a limited number of core ansible modules. (Number of ansible modules comparison between ansible 2.9 vs 2.11 can be found here.)
It seems like the changes were brought in for two reasons:
To provide agility in ansible module development.
To provide a lean ansible execution environment to end-users/developers.
More information will be covered in a separate blog HERE.
3. Ansible Tower is split into smaller bits and utilises containers.
With the announcement of NO MORE ANSIBLE TOWER, the detail is that the Ansible tower is split into two separate components.
As the above shows, the Ansible Tower was in a single monolithic architecture. This works great. However, when there are multiple organizations/teams with multiple python virtual environments requirements, it started to get complicated really quickly.
To address the above, Red Hat has replaced the execution/virtual environments with “Execution Environment”.
The execution environment is a container with various required components.
More information can be found HERE.
The rest of WebUI/API/RBAC/Workflows and Audit components are grouped into “Control Plane”/“Automation Controller”.
4. Red Hat Ansible Automation Platform has a lot more features/components
Colour boxed ones are new components and features brought into the Red Hat Ansible Automation Platform.
* Ansible Platform Operator – Red Hat Ansible Automation Platform is available on the OpenShift Container Platform as an Operator.
This makes installation, operation tasks such as upgrade, easy. Also, provide the high availability capability automatically.
As explained above, these two components replaced the old “Ansible Tower”.
This is a new component that enables an ansible content creator to build a custom/purpose-fit ansible automation execution environment (a.k.a. ansible EE).
This is another new command-line component added to enhance ansible content creator experiences. With new the ansible EE, ansible-navigator should be used as a replacement for all too familiar “ansible” and “ansible-playbook”.
This is one tool that you can run, debug even introspect ansible EEs.
This will be covered in another article, HERE.
* REST of components
So until now, Red Hat Ansible had main 2 components as #1 suggests. On top of that there were few additions to that; * Automation Services Catalog – Service Catalog as a SaaS service on https://console.redhat.com/ansible/catalog/products * Ansible Content Collection – Red Hat and partners co-developed and co-supported ansible contents available https://console.redhat.com/ansible/automation-hub. There are currently 102 partners and Red Hat have contributed content. * Automation hub – a single location where public and private ansible content collections will be hosted. * Red Hat Insights for Ansible Automation Platform – where it provided overall information of an organization’s Ansible automation platform usage as a dashboard.
Definitely, with the new version, the above features got richer.