With the introduction of Ansible Automation Platform 1.2 at AnsibleFest 2020, Ansible released private Automation Hub. This enables a means to deliver, manage and curate Ansible Automation Platform Certified Content via a central on-premises, self-hosted solution for use by internal automation communities.
This sparked my interest in digging deeper into what private Automation Hub is and how I could leverage it. My initial perception went from a mysterious black box to viewing it as the perfect Ansible Automation Platform sidecar.
I learned quite a bit on how I could optimize it for my environments and wanted to share my findings. Before we start, a brief history of Ansible content and Ansible Content Collections may be helpful.
"Following the light of the sun, we left the Old World." - Christopher Columbus on Ansible Collections
During 2017, the number of modules, roles and content under Ansible's GitHub repository surged. The backlog of issues started to increase as the inflow of new content for different platforms and network appliances/devices outpaced the growth of the Ansible Core team. Various YouTube videos and blog posts provided commentary and insights from the Ansible community. The rapid growth of Ansible content led to the birth of Ansible Content Collections as we know them today. What is an Ansible Content Collection? It is nothing more than a standardized directory structure packaged to host content independently from the Ansible command line executable. The content can be playbook examples, roles, modules, documentation or plugins.
You may be thinking, "What does this have to do with Automation Hub?"
Let's find the answer in the library.
The mental representation I have of an automation hub is one of a library. We go to the library to find books. Instead of working with books, this Automation Hub holds Collections. Ansible Galaxy is the largest community repository that hosts a ton of Collections. Everyone can publish their standalone roles and Collections on Ansible Galaxy. It's a fantastic source for various forms of content, but let's face it, some Collections are a work in progress while others are ready for production use. In any case, validating roles or Collections in a test environment is a best practice that one should adhere to. This is simplified using a scoring system on Ansible Galaxy that can help get a sense of a particular Collection's value.
Automation Hub on cloud.redhat.com contains certified Ansible Content Collections and supported ones by Red Hat and a vast ecosystem of partners, available through a valid Red Hat Ansible Automation Platform subscription. As for the private Automation Hub, its purpose is to host your personal Collections and curated content from Automation Hub or Ansible Galaxy. If we look at the total Collections available, Ansible Galaxy hosts by far the most, followed by Automation Hub and private Automation Hub. Red Hat supports both Automation Hub and private Automation Hub represented by the color red in the inverted pyramid diagram above. In contrast, Ansible Galaxy can be seen as the upstream version of Automation Hub and private Automation Hub, represented with the color blue.
"Friends share all things." - Pythagoras on Ansible Galaxy
Below you can find a snapshot of what the interface looks like when logging into private Automation Hub.
On the top left, we have a drag-down menu to select which Automation Hub to work with. Today, we will upload a private Collection into a namespace, so we'll keep the drag-down to "Published", as it represents our private Automation Hub. The private Automation Hub should contain our personal Collections, but other possible use cases include curating Collections from other hubs or making Collections available to air-gap environments.
Once you create a Collection, or receive one that is provided to you in the form of a compressed tarball, you can upload it to your private Automation Hub.
The first step is to select "My Namespaces" and either create a new namespace or select one under where you intend to work. In this example, I’ll create a new namespace that corresponds to my GitHub account named "daleroux" for our demo. This way, we can use my GitHub account to host Collections (or roles) we want to share publicly on Ansible Galaxy or have them uploaded to my private Automation Hub. To simplify for our demo, I will be using the admin account and assign the "admins" group as the namespace owner. Best practice is to create groups and users. For an in-depth understanding of how privileges are assigned, please refer to "Managing user access in private Automation Hub" for more information.
Once my namespace is created, I'll upload the Collection to it by clicking the Upload Collection button in the upper right corner of the page. This action will bring up a Select File window from which I'll select the tar file of my Collection. The archive file undergoes a few validation tests to ensure this is a Collection. Once it is uploaded, someone with "Collections" permissions can approve the Collection. Click on the Approval tab on the left-hand side, and from this window, click on Approve. The kebab menu beside it allows you to reject the Collection or view the import logs.
"If you want a thing done well, do it yourself." - Napoleon Bonaparte on uploading Collections
Now that I have uploaded some private content, I’ll synchronize the content from both Ansible Galaxy and the Automation Hub. There's no point in synchronizing all content in Ansible Galaxy, but instead I’ll specify only the curated content I want to make available to the different teams internally. Selecting "Repo Management" on the left-hand side brings me to the correct location. Clicking on the Remote tab, we're presented with two remote repositories. One being community (Ansible Galaxy), and the other is the Ansible Automation Platform Certified Content on cloud.redhat.com.
Clicking the three dots beside Sync for the community repository brings up an editor to browse and upload a requirements.yml file. In the present case, let's say I want to synchronize only two Collections from Ansible Galaxy, then my requirements.yml file will look as follows:
collections: - name: community.mongodb source: https://galaxy.ansible.com - name: community.general source: https://galaxy.ansible.com
Once I've selected the file, I click Sync to start the synchronization. A checkmark with Completed will appear soon after, under the Sync status. When selecting Community in the drop-down menu at the top left, this content will now be displayed.
Lastly, I’ll synchronize content from Automation Hub to our private Automation Hub instance. The first thing I'll do is log in to cloud.redhat.com and click on Automation Hub under Red Hat Ansible Automation Platform. A new page will be brought up containing a left frame to navigate and click Connect to Hub. From there, I’ll be presented with a configuration page containing the server URL, SSO URL and an offline token. Clicking Load token, it will present a long string to copy to the clipboard. Generating a token will automatically render the old one invalid.
Going back now to my private Automation Hub under Repo Management and selecting the Remote tab, I’ll click on the three dots beside Sync sitting on the rh-certified row. This action will bring up an editor to paste a token.
The content is supported and certified, providing me the option to either sync everything or filter out Collections that I do not wish to synchronize. In the present case, I’ll synchronize everything, so once I paste the token, I’ll click Save and then Sync. The synchronization process may take some time depending on the amount of content.
I created a namespace and uploaded a private Collection to it, synchronized the curated content from Ansible Galaxy, and the entirety of Collections on the Automation Hub to our private Automation Hub.
In my next blog post segment, I’ll show how I integrated Red Hat Ansible Tower with the private Automation Hub.