Hello all,
Got a question regarding execution environments.
Since execution environments are essentially containers (container images), that
are comprised of an operating system, ansible-core, and Python, do they essentially
represent control nodes? Is an execution environment a control node???
Thanks in advance!!!
@Trevor -
So yes, basically from a viewpoint an execution environment replaces the typical control node. The execution environment container image does contain many OS components as well as Python libraries, and collections with various Ansible modules. It is also the EE that contains all the Ansible runtimes and is responsible for making the SSH connections and executing the Ansible playbooks.
This is why some playbooks saving things back to localhost no longer seem to work. As you know, the EE is a running container and containers have ephemeral storage. So traditional playbooks that ran from a local control node would save items back. Since it is the container running the playbook, the item does get saved back, but it is on the read/write overlay filesystem and storage for the container. When executing EEs with the ansible-navigator command, once the execution of the playbook completes, ansible-navigator removes the container which results in the ephemeral storage going away.
On important distinction is that typical containers (including EEs) do not contain a full operating system and are not 100% like VMs. They need some type of container runtime environment (engine) to run. For RHEL-based distributions, that would be podman, but other distributions may use docker. The ansible-navigator command is smart enough to know which containerization technology to use.
Article you might find useful on localhost: https://www.ansible.com/blog/when-localhost-isnt-what-it-seems-in-red-hat-ansible-automation-platfor...
Repository with Examples to mount the true localhost filesystem into an EE: https://github.com/tmichett/do374/tree/main/Demos/Misc/Extra_Mounts
That directory gives you some exact methods of mounting the system filesystem into the EE so it can run like they did on a typical control node.
Feel free to check out. other demos in that repository.
Hope that helps.
Execition Environments (EEs) being containerized are meant to speed up the development process of Ansible playbooks and assist in eliminating issues caused by environmental issues and incompatibilities with various systems not having the correct Python modules or operating system packages.
Execution Environment Images (EEIs) are special container images that are setup to run Ansible playbooks using the ansible-navigator command from developer or system administrator workstations. The EEI contains all packages, Python libraries and dependencies, as well as collections and modules to execute the playbook on any system capable of running the ansible-navigator command and having a container runtime engine.
This allows both the playbooks to be published as well as the EEIs. When using an enterprise-level system, both Private Automation Hub and Ansible Automation Controller are used in conjunction. The needed EEIs are loaded to the Private Automation Hub and then the playbooks are imported into Ansible Automation Controller and set to use the designated EE which comes from the EEI which gets imported into Ansible Automation Controller from Private Automation Hub.
This ensures continuity across systems and that the playbooks can run without special considerations and eliminates developers telling administrators "It worked on my system". Prior to AAP2.x and execution environments, Python virtual environments would need to be setup and installed/configured on Ansible Tower as well as various operating system packages in order to ensure the runtime environment was like a developer's workstation that created the playbook. The introduction of EEs eliminates this dependency and provides a much easier way to transition playbooks from developer systems to operations.
@Trevor -
So yes, basically from a viewpoint an execution environment replaces the typical control node. The execution environment container image does contain many OS components as well as Python libraries, and collections with various Ansible modules. It is also the EE that contains all the Ansible runtimes and is responsible for making the SSH connections and executing the Ansible playbooks.
This is why some playbooks saving things back to localhost no longer seem to work. As you know, the EE is a running container and containers have ephemeral storage. So traditional playbooks that ran from a local control node would save items back. Since it is the container running the playbook, the item does get saved back, but it is on the read/write overlay filesystem and storage for the container. When executing EEs with the ansible-navigator command, once the execution of the playbook completes, ansible-navigator removes the container which results in the ephemeral storage going away.
On important distinction is that typical containers (including EEs) do not contain a full operating system and are not 100% like VMs. They need some type of container runtime environment (engine) to run. For RHEL-based distributions, that would be podman, but other distributions may use docker. The ansible-navigator command is smart enough to know which containerization technology to use.
Article you might find useful on localhost: https://www.ansible.com/blog/when-localhost-isnt-what-it-seems-in-red-hat-ansible-automation-platfor...
Repository with Examples to mount the true localhost filesystem into an EE: https://github.com/tmichett/do374/tree/main/Demos/Misc/Extra_Mounts
That directory gives you some exact methods of mounting the system filesystem into the EE so it can run like they did on a typical control node.
Feel free to check out. other demos in that repository.
Hope that helps.
Execition Environments (EEs) being containerized are meant to speed up the development process of Ansible playbooks and assist in eliminating issues caused by environmental issues and incompatibilities with various systems not having the correct Python modules or operating system packages.
Execution Environment Images (EEIs) are special container images that are setup to run Ansible playbooks using the ansible-navigator command from developer or system administrator workstations. The EEI contains all packages, Python libraries and dependencies, as well as collections and modules to execute the playbook on any system capable of running the ansible-navigator command and having a container runtime engine.
This allows both the playbooks to be published as well as the EEIs. When using an enterprise-level system, both Private Automation Hub and Ansible Automation Controller are used in conjunction. The needed EEIs are loaded to the Private Automation Hub and then the playbooks are imported into Ansible Automation Controller and set to use the designated EE which comes from the EEI which gets imported into Ansible Automation Controller from Private Automation Hub.
This ensures continuity across systems and that the playbooks can run without special considerations and eliminates developers telling administrators "It worked on my system". Prior to AAP2.x and execution environments, Python virtual environments would need to be setup and installed/configured on Ansible Tower as well as various operating system packages in order to ensure the runtime environment was like a developer's workstation that created the playbook. The introduction of EEs eliminates this dependency and provides a much easier way to transition playbooks from developer systems to operations.
What can I say Travis. With you, it's not steak or lobster, it's steak and lobster!!!
This explanation has absolutely answered my question, and moved the needle of
my understanding along the way!!!
I'm beyond grateful good sir!!!
Travis, your explanations are definitely not the equivalent of fast food. They are more
like eating at a 5-star steakhouse!!!
Many, many, many thanks for your usual exemplary reply!!!
@Trevor -
Always happy to help. It is difficult to wrap your head around some of the changes after being used to Ansible for years and functioning a single way. It is especially hard when we have things that are named essentially the same but do somewhat different things.
I had suggested using the Ansible 2.9 compatibility EE to lots of people so they didn't need to worry about refactoring playbooks for fully qualified collection names or be as impacted regarding the changes where Ansible no longer had "batteries included" and that works in almost all cases.
Then when someone said my playbooks always used to work until AAP, I looked at the playbook in class and saw they were bringing back information to the local machine but in the playbook saving it to "localhost" which is why I came up with a few demos in the DO374 course which was our initial course to get people used to Execution Environments.
This is really awesome that you are working on getting a better understanding here and bringing things to Red Hat Academy. I will be delivering another RH294 next week so I expect to be updating some more of my playbooks and demos for that course and I imagine you've got that as part RHA deliveries.
https://github.com/tmichett/RH294
Feel free to start looking here, asking questions, and submitting issues. I'm sure I will add and change some more things around. I know I have a few demos in there that might be a little more advanced for a regular RH294, but they might be good in a longer RHA delivery since I think you all treat those as a semester-long course.
Figured you might need some dessert to go with that steak and lobster. The git repo can be your take-home goodie bag.
Travis, your opening paragragh was a clear indication that you understand
my pain point!!! You are so, so right!!! Just when I was getting settled in
with Ansible, doing my thing from the CLI only, along comes this monster
Ansible Automation Platform. It was sort like spending months learning how
to fly a single-engine prop aircraft, and then being placed in the cockpit of
a 747, and told "okay, show us what you got"! Yeah, there was some familiarity
in the cockpit. But jet engines (i.e. automation controller)? And what are the
other controls (Smart Inventories, Automation Mesh, Automation Private Hub, etc.)?
Ouch!!!
Just in case there wasn't enough pain already, the objectives for the EX467 get in
on the act. The very first objective refers to Private Automation Hub. The very last
objective makes reference to Ansible Private Hub. Huh? Are Private Automation Hub
and Ansible Private Hub really 2 different entities? Is it "washing power" or
"soap powder"
Anyway, I guess the tone of my questions helped you with the diagnosis. I mean,
you hit the nail on the head with your comments, doctor. What's my bill
Well, just like every other application that has forced me to retool, I'll eventually
get settled in with AAP. I'll kid, I mean motivate myself, by saying, "It's just another mountain, only higher" !
Travis, thanks for all the coverage - thus far. Your input has definitely served
to help me gain my balance!!! Oh yes, and it was a very, very nice desert to
follow the steak and lobster !
This has a typo. All this marketting and the web teams sometimes mess things up. Basically you have objectives to install and configure Ansible Automation Controller (used to be called Ansible Tower => upstream project AWX) and Private Automation Hub (upstream project Ansible GalaxyNG).
You are supposed to work with and configure both of these applications and use them to perform whatever tasks are in the objectives. The last objective should say backup both Ansible Automation Controller and Private Automation Hub.
https://github.com/tmichett/do467_notes
Really good notes for DO467 ^^^ and sample demos/playbooks and things to setup the environment and go further.
https://github.com/tmichett/do467_tot - Taste of Training Webinar
https://github.com/tmichett/AAP_Webinar - AAP2 Webinar
The webinar references above might also provide some help. I think the Taste of Training Webinar is gone, but for the AAP2 webinar, I saved the Vimeo video there.
@Jacqueline - Is this something you can have the Web/Marketting team look at for the exam objectives as there are inconsistencies with the product name which is causing some confusion.
Hello Travis,
I didn't mean to lay the naming inconsistences matter at your doorstep.
I know this is not your responsibility. However, as always I appreciate
your comments, as well as bringing this to the attention of someone on
the Web/Marketing team who might be able to make the necessary
adjustments.
Thanks for directing me to your DO467 resources, and the AAP webinar
on Github. Great, great stuff!!!
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.