Using the access information/credentials provided make sure you can log into to your:
Let’s start, as the docs for this are distributed over some places we’ll give some more instructions.
In this lab your automation controller was already configured during installation to fetch collections from PAH and Ansible Galaxy. The first task is to disable direct retrieval of collections from Ansible Galaxy so only collections on PAH could be used.
defaultOrganization in Automation Controller and click Edit
You could add more credentials here, the order of these credentials sets precedence for the sync and lookup of the content.
It’s important to note that the PAH credentials are added automatically during an installation of Automation Controller and PAH in one installer run. If you add PAH later you have to configure the credentials yourself!
Before we configure content synchronization, we want to add a demo project:
You will notice this project will fail to sync (Click on the Jobs menu on the left) with an error “ERROR! Failed to resolve the requested dependencies map. Could not satisfy the following requirements: containers.podman”. This is because the
requirements.yml file lists a dependency for a collection which is not yet available to your controller.
To solve this issue, we have to configure your PAH to sync the necessary collections, and to configure your automation controller to use the content from your private automation hub. We did already configure automation controller, but we haven’t synced any content yet.
Most of this is well documented here
console.redhat.comand open Ansible Automation Platform -> Automation Hub -> Collections. Here you can enable/disable the sync of certain collections. You will need a RHN account with “organization administrator” privileges to perform this action.
If you never modified your sync settings in Automation Hub before, all collections will be synchronized. To speed up the sync time, we recommend to disable as many as you can - but not all of them.
Galaxy is configured as the remote
community out of the box. Follow the instructions to configure the synchronization.
collections: # Install a collection from Ansible Galaxy. - name: containers.podman
requirements.ymlfile from your local machine.
Verify the sync of the collections in Collections -> Collections, switch the repository filter with the dropdown at the top. There should be a lot of content in the
Red Hat Certified repo and one collection in the
Community repo. The ‘published’ filter will not find anything, since we haven’t uploaded any collections we created ourselves.
Now check that Automation Controller can actually use the content from your PAH. Let’s first sync our project again and the error message should disappear because now automation controller can download and install the collection from your private automation hub.
Before we can test with an actual Playbook, we have to create an inventory in Automation Controller. Create an inventory called Workshop Inventory and populate it with the unique name of
node1 listed in
/etc/ansible/hosts in the “managed_nodes” section:
$ cat /etc/ansible/hosts [output truncated] [managed_nodes] node1.<LABID>.internal node2.<LABID>.internal node3.<LABID>.internal
Make sure you only create
node1, we will need the other nodes later!
We also have to create machine credentials for these servers. Let’s create machine credentials called Workshop Credentials. Use the private key of
lab-user from the VS Code Server terminal and as username
For a proper end to end test, let’s create a Job Template that uses the
containers.podman collection which is not part of the included Execution Environments:
Sync the project you created earlier again and check it runs successfully. You should notice from the job output that the task which installs collections from the
requirements.yml is now succeeding.
Create a new Job Template:
Ansible Engine 2.9 execution environment
Launch the Template
It should now run and deploy an httpd container on
node1 that is hosting a small website. Test it from the terminal in VS Code Server:
So recap what happened:
default) is configured in a way it can only download Collections from your Private Automation Hub
As this collection is not part of the Execution Environment the Playbook uses, how did it work? In this case is it was dynamically “added” to the Execution Environment at runtime. This behavior did already exist in Ansible Tower 3.8, and it still does work in automation controller. This means, you only have to build your own execution environment if your collection has additional Python or package dependencies. You can double check by looking at the details of the “source control update” job of your project and click on the “fetch galaxy collections from collections/requirements” task.
Be able to manually configure private automation hub to synchronize content from Red Hat’s automation hub and Ansible Galaxy.
You should also better understand that, although it might be beneficial to create custom execution environments, it’s not always necessary and automation controller can still load and install collections during runtime.