Ansible Automation Platform Projects

Overview

This article will provide instructions in how to configure Ansible Automation Platform (AAP) and how to get your Project working. Links for various fields that I don’t need in my environment is provided at the end of this article.

Organizations

Before you can do anything, you need to create an Organization as all additional information is associated with an Organization. In the AAP console, click on Organizations, then Add. You’ll be presented with several fields. Fill in the Name and Description.

An Instance Group is a collection of Instances. This lets you run jobs on specific isolated containers. Otherwise all jobs run on the AAP container.

An Execution Environment replaces the Python virtual environment. This gives you a customized image to run jobs where some dependency isn’t impacted by the requirements of a different job.

For my environment, I’ll leave these two fields blank and use the default for the Galaxy Credentials.

Git Repository Access

Next up we need to access Gitlab in order to pull a repository into AAP. To do you, we need to create a Personal Access Token. In Gitlab, under your account and preferences, click on the Access Tokens link and create your token. I don’t need AAP to write back to the repository as it’s just applying configuration information for Kubernetes. So just select the read_respository option and a reasonable name and expiration date.

In AAP , click on the Credentials link and click the Add button. Add a Name, I used Gitlab Access Token, a Description, and of course the Organization you created. Under Credential Type, select Gitlab Personal Access Token. When you select that, a Token field is displayed. You’ll add your Access Token here.

Machine SSH Key

I’m using a SSH private/public RSA key and a service account to run ansible playbooks. My service account has passwordless access to sudo to root on all servers so I don’t need to pass in a service account password.

Next up then I need to create a Machine Credential for my Service Account. In the Credentials link, select the Machine Credential Type. Several fields are now available. If you use password access, you will fill in the necessary information. If you’re using a SSH Key, you can enter your passphrase here as well. In my case, I add my SSH Private Key for the service account and it’s ready to go.

Projects

At this point, we can access the repository and bring in the ansible playbooks. First though, you’ll need the ssh link to your repository. In GitLab, navigate to that repository, click on Clone, and copy the Clone with SSH link.

In AAP, click on Projects and Add. Enter a Project Name and Description. Select the Organization. If you’re validating content, select the appropriate Content Signature Validation Credential. And for the Source Control Type, select Git. This brings up several additional fields specific to the Git selection. Paste the SSH Clone Link into the Source Control URL field. Under the Source Control Branch/Tag/Commit field, add in the branch, tag, or commit id you want to use for the Project. And under the Source Code Credential field, select the SSH GitLab Accesscredential you created earlier.

Branch/Tag/Commit

A quick aside here on this field. If you are deploying to multiple environments, you might consider different strategies for the Projects. For example, the Development environment might be better using a branch strategy as every change then gets applied to the development server(s). For non-Production environments, you might use a git tag to lock in a release. And for Production, you’d use a commit id. This locks Production so even an accidental push to the repository won’t cause Production to update until you’re absolutely ready.

Inventories

One of the things I want to do is have git manage the inventory files, for my environment that’s GitLab. There are three options for an Inventory but for inventories managed in a repository, select just Inventory from the drop menu and fill out the Name, Description, and Organization, then Save the Inventory.

Once the inventory is created, select it. There are several tabs, one is Sources. Click the Sources tab and click on Add. Enter a Name and Description for the inventory, then select Sourced from Project from the Source drop down. Additional fields will be displayed.

For mine, I selected the Playbooks Project. I will note that my inventory files are automatically created by my Inventory web application. Scripts create both a hosts INI file and a hosts YAML file. For purposes of this exercies, both are under the inventory directory of the Playbooks Project. Unfortunately when you select the Inventory file drop down, the file doesn’t show up in the listing. You can type in the file though. I entered inventory/hosts to use the INI file. While Ansible doesn’t care if the INI file has duplicate entries and will consolidate them all into one set of servers, the ansible YAML parser complains and only uses the last entry, ignoring any previous duplicates. There are other fields you can also update but I saved mine as I just wanted the hosts INI file.

Click Save and then either click the Sync all button or if more than one inventory exists, click the circling arrows to the right of the Inventory. Depending on the number of hosts, it may take a few minutes for all the hosts to register.

Templates

Finally in order to run your playbooks, you need to create a Template. Select Templates and click on Add. There are two options on the drop down menu; a Job Template for a single task or a Workflow Template for multiple tasks such as a pipeline. For this article, select a Job Template.

Several fields are now available to create the template. Enter in a Name and Description. A Job Type drop down lets you Run the job or Check the job before running (the -C or –check on the command line). Select the Inventory to use, the Project, and within the Project, the Playbook you want to run. For Credentials, I’m selecting the Machine ssh one as it’s my service account that has authority to run the playbooks.

For this article, I’m using my Unixsuite playbook which ensures my standard scripts are on all my servers. I do want to have each environment run separately though so I’m creating multiple Templates. I typically pass the variable as ‘pattern=[env]’. Since this isn’t the command line, I’ll have to add it in the Variables box. My QA environment uses the ‘cabo0’ prefix and pattern is the variable in the playbook so the following should be entered in the Variables box:

---
pattern: "cabo0"

Once saved, click the Template, then click the Launch button to make sure it works. Once you’re sure it’s working as expected, go back to the Templates and select the newly created Template. Click on Schedules and Add. Create a Name and Description. Select a Repeat frequency, I selected weekly. This brings up a few more fields where you can further customize the schedule. I selected Saturday and Never for when it Ends. Then a Start date/time. Since I’m doing it weekly on Saturdays, I selected 11:15pm. Then Save it.

References

• Instance Groups
• Execution Environments