GitOps Pipeline for an Execution Environment (EE) with Ansible Collections

Projects: c2platform/rws/ansible-gis, c2platform/ansible-collection-core, c2platform/ansible-collection-mw, c2platform/rws/ansible-execution-environment, c2platform/ansible-collection-mgmt

Introduction

When using the Ansible Automation Platform (AAP), there are three strategies for managing Ansible collections:

1. Include collections in the EE.
2. Pull collections using requirements.yml¹.
3. A combination of both.

Each approach has its pros and cons. A significant downside of using an EE is that the EE and its version are defined externally in AAP, preventing a pure GitOps approach. This how-to guide describes how to use an AAP Workflow and an Ansible Job Template to configure AAP to use a specific EE version before other Job Templates run. The Job Template utilizes the Ansible role c2platform.mgmt.awx to manage the EE version. Red Hat recommends using only the EE for performance reasons²

Collection Strategies

Only use the requirements.yml file

This is easy and flexible, suitable at the start of a project when many updates are made to collections. The downside is longer job times as collections are fetched each time.

---
collections:
   - name: c2platform.core
      version: 1.0.21
   - name: https://gitlab.com/c2platform/rws/ansible-collection-wincore.git
      type: git
      version: master

Show Diagram

Only use the EE

Jobs run faster on AWX. The downside is the need to release new versions of the collection and EE and manually configure the new EE version in AWX³.

Show Diagram

Use both the EE and the requirements.yml**

Add community collections to the EE and use requirements.yml for frequently updated collections.

A downside to adding collections to the EE is that it complicates a DTAP promotion model setup in Git. This can be overcome by setting up a workflow in AWX that configures the correct EE version.

Prerequisites

• Ensure gsd-awx1 is up and running. Refer to Setup the Automation Controller (AWX) using Ansible.
• Configure SSH connections if running Ansible plays without Vagrant. Refer to Using Ansible without Vagrant.

Change the EE

This section demonstrates how to change the EE in AAP in a workflow job so that the new EE becomes available to jobs that run after that job.

This section demonstrates how to change the EE in AAP in a workflow job so that the new EE becomes available to jobs that run after that job.

1. In the ansible-gis project, switch to the development branch and edit group_vars/awx/awx.yml. Define gs_ee_images as follows:

   gs_ee_images:
     default: registry.gitlab.com/c2platform/rws/ansible-execution-environment:0.1.18
     development: quay.io/ansible/awx-ee:24.4.0
   

   Remove or disable the line with development, commit, and push back to the development branch.
2. Navigate to https://awx.c2platform.org/#/execution_environments  . Verify that quay.io/ansible/awx-ee:24.4.0 is the EE.
3. Navigate to https://awx.c2platform.org/#/templates  and click on the Visualizer link of gsd-awx-collections-workflow. This shows a workflow with five nodes.
4. Launch the workflow.
5. When the workflow completes, verify that gsd-collections1 shows quay.io/ansible/awx-ee:24.4.0 and gsd-collections2 shows registry.gitlab.com/c2platform/rws/ansible-execution-environment:0.1.18.

This demonstrates that we can include the EE in our DTAP promotion model similarly to how we use the requirements.yml file by setting up a workflow that includes a job like gsd-awx-ee to manage the EE for the environment.

Promote the EE

This section shows how we can promote changes, including the EE, from development to test.

1. Create the configuration in AWX for the test environment using node gst-awx1⁴:

   export PLAY=plays/mgmt/awx_config.yml
   ansible-playbook $PLAY -i hosts.ini --limit=gst-awx1
   

   Note:

   Running Ansible commands directly will only work if you set up the necessary SSH configuration for it. Refer to Using Ansible without Vagrant for more information.
2. Using the AWX web interface, launch gst-awx-collections-workflow.
3. After completion, verify no difference between collections in gst-collections1 and gst-collections2.
4. In the development branch, change the default image to 0.1.19. Commit and push.

   gs_ee_images:
     default: registry.gitlab.com/c2platform/rws/ansible-execution-environment:0.1.19
     development: quay.io/ansible/awx-ee:24.4.0
   

5. Merge changes to the test branch and launch gst-awx-collections-workflow.
6. After completion, verify differences between outputs of gst-collections1 and gst-collections2.

Review

In the Ansible Inventory project c2platform/rws/ansible-gis:

1. The play plays/mgmt/awx.yml, which shows Ansible roles utilized to create the gsd-awx1 node.
2. Files inside group_vars/awx. These files contain configuration.
3. The file Vagrantfile.yml, which defines the Vagrant LXD machine.

The Ansible role c2platform.mgmt.awx in the Ansible Management Collection c2platform/ansible-collection-mgmt. This role uses modules from the awx.awx collection to configure AWX (job templates, workflows).

The Ansible roles c2platform.mw.microk8s and c2platform.mw.kubernetes in the Ansible Middleware collection c2platform/ansible-collection-mw. The first role creates a Kubernetes instance; the second installs AWX on the cluster.

Tips

If you are experimenting or developing with AWX configuration, you can use tags to speed up provisioning:

export PLAY=plays/mgmt/awx_config.yml
ansible-playbook $PLAY -i hosts.ini --limit=gsd-awx1 --tags secrets,awx_workflow_job_template,awx_workflow_job_template_node

You can also use tags when using Vagrant:

export PLAY=plays/mgmt/awx_config.yml
TAGS=secrets,awx_workflow_job_template,awx_workflow_job_template_node vagrant provision gsd-awx1

Notes