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.

• Name – This is selected for every additional task done in AAP.
• Description – A reasonable description of the Organization.
• Instance Group – A collection of Container Instances. This lets you run jobs on specific isolated containers. Otherwise all jobs run on the AAP container.
• Execution Environment -This 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.
• Galaxy Credentials

User Management

While the Admin can make changes, the Admin should really only be administering the cluster and not dealing with the day-to-day work.

The next step then is to add the users. Under Access, click Users and fill in the form. Under User Type, there are three. Normal User, System Auditor, and System Administrator.

• Normal User – General access used by all members
• System Auditor – Read-Only access to the entire environment
• System Administrator – Admin access to the cluster.

Group Management

In AAP, Teams manage access to the various parts of an Organization. When a team member creates something such as Credentials, only that team member can use that Credential. If the Credential is to be used by all, then the Team would need to be given permission to access that Credential. Then all members of the team have access.

The next step is to create the necessary team(s). Under Access, click Teams and create the new team.

To add members to the team, under Access, click the Users link. Select the user you want to add. Under the Teams tab, select the team(s) the member should belong to.

GitLab Personal Access Token

Next up we need to access Gitlab in order to pull a repository into AAP. To do so, we need to create a Group Access Token. In Gitlab, under the group account, External-Unix in my case, your account and preferences, click on the Access Tokens link and create the 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. While it’s actually a Group Access Token, there isn’t an option for that in the menu. When you select it, a Token field is displayed. You’ll add the Group Access Token here.

Machine Credential

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.

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.

Source Control Credential

In order to pull code from GitLab using the ssh link, we need to create a Source Control Credential. Click Add to create a new Source Control Credential. Similar to the Machine Credential, fill out the fields and then add the private ssh key used when you push git updates to GitLab.

Projects

Now that all the Credentials have been created, 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 Access to GitLabcredential 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 review. For pre-Production environments such as a QA or Staging environment, 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.

Under Project, select the Playbooks project. If there, select inventory/hosts from the Inventory file drop down. If it’s not there, you can manually enter it. Check the Overwrite checkbox to clear old systems that have been retired or otherwise removed from the hosts file. Upon the next sync, they should disappear from the list of Hosts. Verify it by checking the Hosts link. If they still exist, you can click the slider next to the host to remove it from consideration until AAP clears the entry.

I will note that my inventory files are automatically created by my Inventory web application. This file is then copied into the inventory directory of the Playbooks repository. Since it’s unlikely to happen often, you don’t have to set up a job to sync regularly.

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.

Teams Management

Now that you’ve created all these entries to have your project run regularly, no one else on the team will be able to manage the bits you’ve created. Not until the Team has access.

Under Access, click Teams and then click on the Team you want to modify. Click the Roles tab to begin to assign Roles.

You’ll be presented with multiple options for what can be added to the team. I’ve selected Credentials in this case as I want the team to be able to access GitLab. Click Next to select the Credentials to add.

As you can see, the last three are the Credentials we created in this article. Click the three checkboxes and click Next.

Finally select the rights the team has to the selected credentials. In general Use access is sufficient and assumes you want no one else to manage the selected credentials. Once you’ve selected the rights, click Save and all members of the team have access.

You’ll want to do the same thing with other permissions. Access to inventories, playbooks, templates, and so on are granted through the teams interface. By default only the creator has access to the tasks they created.

References

This section provides links to the Ansible documentation. The steps in this article provide the order in which to configure my Ansible Automation Platform (AAP) installation. The links provide more detail that might be beyond the scope of my requirements.

• Organizations – More information on the form
• Users – View the different User Types
• Teams