RHEL 10 and Ansible

[Trevor]

Now that RHEL 10 has set sail, the ansible package that has been avaiable 
in previous RHEL versions, is deprecated, and no longer available in either
official Red Hat or EPEL repositories.  The recommended base package in
RHEL 10 is now ansible-core - this provides only the essential automation engine. 
I say only, but just like on a vehicle, this (automation engine) is thee key component.

To gain the full functionality that was provided by the deprecated ansible package,
the necessary collections must be explicitly installed.

All-in-one ansible package - no more!

[Chetan_Tiwary_]

@Trevor spot on! Instal ansible-core , then create a requirements.yml for the collections you need and then install those via ansible-galaxy. 

[Travis]

@Trevor -

The package has been ansible-core for quite some time. One thing is that things like ansible-navigator comes from an AAP subscription. However, as of RHEL10, RPMs for those tools will no longer be provided. Instead, we have a DevTools container and configuration for VSCode. This container contains all the Ansible development tools needed to develop in Ansible for AAP 2.5 and beyond. This DevTools container allows you to run Ansible Navigator using whatever execution environments that you could have used for RHEL8 or RHEL9. 

Our upcoming RHEL10 version of the AU294 (replacement for RH294) will showcase the setup of VSCode and the DevTools container. We have already released the first lesson into production that covers how to use the DevTools container.

https://rol.redhat.com/rol/app/courses/au0018l-2.5/pages/ch01s03

A Fedora Version: https://ansible.readthedocs.io/projects/dev-tools/container/

Video Walkthrough: https://www.youtube.com/watch?v=kOGs6Ntt8JY

RHEL10 Docs: https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/developing_aut...

Overview from Upstream: https://ansible.readthedocs.io/projects/team-devtools/

Upstream Python Tools: https://github.com/ansible/ansible-dev-tools

[Trevor]

Travis, this is a lesson that will definitely raise my knowledge level!

Thank you!!!

[Trevor]

Travis, just when the mental block was about to be removed, 
I read something that reestablished it.

Okay, how about a lesson on how ansible-core and AAP EE
fit together - if they do at all.  I know I'm making this more 
challenging than it has to be.  That abusive use of the word
"Ansible" is just a bit much for my limited intelligence.  I'm 
going to need medical attention from an overdose of the use
of that one word - Ansible

Thanks Travis!!!

[Travis]

So ansible-core is the name of an RPM group of applications that are installed directly on a Red Hat Enterprise Linux system or its variants. When ansible-core is installed, you get several commands which are:

• ansible (Runs/Executes ad-hoc tasks using a single Ansible module)
• ansible-playbook (Runs/Executes playbooks containing one or more tasks which each rely on an Ansible module)
• ansible-inventory (Command to show Ansible inventory)
• ansible-galaxy (Command that allows installing Ansible roles and collections which contain modules and roles)
• and several other commands.

AAP EE is more of a concept and can be different things. With AAP, you are running what is called an execution environment. An EE is nothing more than a container running from a container image. This container image has ansible-core plus a whole bunch of other things already installed (Python libraries, Ansible roles, Ansible collections). Prior to AAP, Ansible used to have all the modules built-in (batteries included), gradually, these modules have been separated into collections (Phase 1), then with passage of time, Ansible transitioned to more of an "enterprise" managed deployment and decided to leverage containers more which introduced ansible-navigator which allows the running of playbooks using containers (know as Execution Environments - EEs). So there are several AAP EEs out there. The RHEL8-Supported or RHEL9-Supported EEs have ansible-core installed already, plus a large amount of supported collecitons which have several other modules and Python components pre-installed. This allows for faster development of modules and collections without depending on newer versions of Ansible to be released. Prior to this, when a module needed updated, it was tied to the Ansible development cycle and you would need to wait for a module to be released. One of the hardest changes might have been the ansible.posix collection because the synchronize and firewalld modules are part of that collection and it is no longer deployed when installing Ansible as that is just typically ansible-core.

I would encourage you to look at the presentation I attached on another post describing how containers work in terms of AAP. I also know you were in one of my courses where we covered Podman and how containers work, so a thing you could do for fun is to take an Ansible EE and use the podman run -it <EE_Name> /bin/bash and get a shell inside the EE. You will see it is just a container with ansible-core and other things installed. The ansible-navigator command essentially does a bind mount with Podman using -v to mount in the current working directory. If you change the above Podman command you can mount your playbook directory into the EE and use the ansible-playbook command to run a playbook or you can use the ansible -m <module> to run ad-hoc commands with just Ansible from the installed ansible-core package within the AAP EE.

The other reference post is: https://learn.redhat.com/t5/Automation-Management-Ansible/Ansible-Playbook-Format/m-p/54648#M1644 

[Trevor]

Thank you Travis!  That mental block is starting to breakup!!!

[bonnevil]

@Trevor Some of the confusion also comes with the distinction between the community-managed upstream projects and Red Hat's supported products.

Upstream, ansible-core (which Red Hat provides as the ansible-core RPM package in RHEL, and upstream provides from PyPI) are the core components of Ansible that @Travis talked about in his posting.  The upstream documentation for it is https://ansible.readthedocs.io/projects/ansible-core/devel/.  It's a bit limited because it only includes the ansible.builtin Ansible Content Collection.

Upstream provides an "Ansible" PPA through PyPI that includes a whole set of additional Ansible Content Collections (and that shouldn't be confused with the ansible command for ad-hoc commands in ansible-core). This is more like what Red Hat provides inside our automation execution environments for AAP like ee-supported-rhel9, except it's installed to the workstation for ansible-playbook to use, and it's likely to be a slightly different set of Ansible Content Collections.  (Upstream might have a different idea of what they want to provide than Red Hat wants to officially support.)

RHEL includes just ansible-core as an RPM package, and a handful of additional roles or Ansible Content Collections, and it's mainly meant as a convenience to do things like run RHEL System Roles.

AAP is close to being like the upstream Ansible distribution in PyPI, except Red Hat packages up (a potentially slightly different set of supported) Ansible Content Collections in execution environment container images to make them more portable between systems, and encourage folks to use ansible-navigator and automation controller to run their playbooks inside those standard Ansible environments.  Red Hat does that because we ran into folks that needed to run, for example, older versions of an Ansible Content Collection that needed different Python libraries than usual, and they couldn't install the old version at the same time as other collections needed by other playbooks due to conflicts and so on.  For example, at one point older (supported) versions of Red Hat Virtualization couldn't use the latest collection, but the current supported version required it.

So folks could have a special EE just for playbooks using that older Ansible Content Collection, and use the standard EE for other playbooks, and everything would just work.  It also makes it easier to move a playbook from a developer's workstation to another developer's workstation or production if all three use an Ansible installation in the same EE container image to run.  This made installing Ansible a lot simpler for dealing with that sort of use case.