Trevor
Starfighter Starfighter
Starfighter
  • 585 Views

Running Ansible Playbook - AAP-2.2

Jump to solution

Got several dots that I need to connect, but I won't attempt to connect
them all in a single post.

Statement: When I run a playbook with ansible-navigator, I can select an
automation execution environment for ansible-navigator to use to run that
playbook.  

Question 1: When running a playbook in this manner, is automation controller
                  involved at all?

Question 2: When running a playbook in this manner, are either of the node types
                      ( control, execution, etc.) of AAP-2.2 involved at all?  I'm pretty 
                      certain hop nodes are not (ncessarily) involved here, and I feel the
                      same about hybrid.


I have my own answer, but I'm only willing to bet three-quarters of the ranch that
I'm correct
    
Anyway, I'll start with these 2 queries.

 

 

 

 

Trevor "Red Hat Evangelist" Chandler
1 Solution

Accepted Solutions
Travis
Moderator
Moderator
  • 571 Views

@Trevor -

See your other post about node types for definitions as they are part of the Automation Controller infrastructure.

https://learn.redhat.com/t5/Enable-Sysadmin-Community/Ansible-Automation-Platform-node-types/m-p/377...

When you are leveraging ansible-navigator command locally, it is used as a "wrapper" of sorts to launch the container (execution environment) and run/execute the playbook on the managed nodes. This process 100% does not involve any of Ansible Automation controller so none of the node types are used. It is leveraging either Podman (if a RHEL-based system) or possibly (Docker) as the container runtime tools and then launching the container image (the execution environment image) as a running container (the execution environment) to run your playbook as the EE contains all the ansible-core runtime components, any collections, all Python modules needed, and anything else based on the reasons you chose an EE.

Again, the EE makes the playbooks more portable and prevents the need of ensuring that all workstations or systems be configured a certain way (certain Python libraries and versions, certain OS packages, etc.) meaning if someone develops a playbook for an EE named quay.io/tmichett/aap-ee-2.4:latest then as long as someone else downloads and uses that playbook with either ansible-navigator or Automation Controller, it should be able to be run successfully without any specialized configuration.

Keep in mind from the node-types that Automation Controller is at the "enterprise-level" and it uses execution nodes to actually use a process to launch the running execution environment and playbook. Again, the "Hybrid" and "Execution" node types are the only ones actually running a playbook.

A hop node in this enterprise environment is only needed to provide SSH access. On a local system, you would more likely have an SSH-Jumphost setup in you SSH configuration files for when you can't SSH directly to a system. That is the only reason to have a Hop node in the Ansible Automation Mesh (to get to systems that have no direct access).

The DO467 course has some excellent explanations on this for further reference. Keep in mind, Ansible Automation Controller replaces and is the new incarnation of Ansible Tower. So this is more for automation at large scale and used by many enterprises. In order to provide developers and administrators the correct tools, ansible-navigator is used. It prevents the age-old developer/admin battles of it worked on my machine, it is your problem now ... there is nothing wrong with my code (playbook in this case).

Prior to ansible-navigator it is possible that some Python libraries, collections, modules might be available on developer machines or individual workstations but not on the central ansible controller (pre-AAP 2.x) or Ansible Tower. This caused playbooks not work because OS libraries are missing, Python modules were missing, Ansible modules were missing. Administrators would need to figure that out (especially when using Ansible Tower) and create Python venv (Virtual environments) for various playbooks which was a nightmare as well as installing additional packages to controller (again after failures to run a working playbook and hours of investigation.)

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training

View solution in original post

2 Replies
Travis
Moderator
Moderator
  • 572 Views

@Trevor -

See your other post about node types for definitions as they are part of the Automation Controller infrastructure.

https://learn.redhat.com/t5/Enable-Sysadmin-Community/Ansible-Automation-Platform-node-types/m-p/377...

When you are leveraging ansible-navigator command locally, it is used as a "wrapper" of sorts to launch the container (execution environment) and run/execute the playbook on the managed nodes. This process 100% does not involve any of Ansible Automation controller so none of the node types are used. It is leveraging either Podman (if a RHEL-based system) or possibly (Docker) as the container runtime tools and then launching the container image (the execution environment image) as a running container (the execution environment) to run your playbook as the EE contains all the ansible-core runtime components, any collections, all Python modules needed, and anything else based on the reasons you chose an EE.

Again, the EE makes the playbooks more portable and prevents the need of ensuring that all workstations or systems be configured a certain way (certain Python libraries and versions, certain OS packages, etc.) meaning if someone develops a playbook for an EE named quay.io/tmichett/aap-ee-2.4:latest then as long as someone else downloads and uses that playbook with either ansible-navigator or Automation Controller, it should be able to be run successfully without any specialized configuration.

Keep in mind from the node-types that Automation Controller is at the "enterprise-level" and it uses execution nodes to actually use a process to launch the running execution environment and playbook. Again, the "Hybrid" and "Execution" node types are the only ones actually running a playbook.

A hop node in this enterprise environment is only needed to provide SSH access. On a local system, you would more likely have an SSH-Jumphost setup in you SSH configuration files for when you can't SSH directly to a system. That is the only reason to have a Hop node in the Ansible Automation Mesh (to get to systems that have no direct access).

The DO467 course has some excellent explanations on this for further reference. Keep in mind, Ansible Automation Controller replaces and is the new incarnation of Ansible Tower. So this is more for automation at large scale and used by many enterprises. In order to provide developers and administrators the correct tools, ansible-navigator is used. It prevents the age-old developer/admin battles of it worked on my machine, it is your problem now ... there is nothing wrong with my code (playbook in this case).

Prior to ansible-navigator it is possible that some Python libraries, collections, modules might be available on developer machines or individual workstations but not on the central ansible controller (pre-AAP 2.x) or Ansible Tower. This caused playbooks not work because OS libraries are missing, Python modules were missing, Ansible modules were missing. Administrators would need to figure that out (especially when using Ansible Tower) and create Python venv (Virtual environments) for various playbooks which was a nightmare as well as installing additional packages to controller (again after failures to run a working playbook and hours of investigation.)

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
Trevor
Starfighter Starfighter
Starfighter
  • 560 Views

Travis -

Your reply has me feeling very, very empowered!!!

That one sentence, "This process 100% does not involve any of Ansible Automation
controller so none of the node types are used", really rang the bell for me.  I'm talking
about ding, ding, ding!!!

I digiested long ago, the fact that Automation Controller replaced Ansible Tower.
If only some of these other concepts were that easily digestible

As always, you continue to elevate my understanding with your exemplary replies!!!

Thank you!  Thank you!  Thank you!

Trevor "Red Hat Evangelist" Chandler
Join the discussion
You must log in to join this conversation.