Ansible Tower and its ‘venv’ Lifecycle on OpenShift

5 min readAug 2, 2021

If you have been working with Ansible Tower or AWX you know what are virtual environments and how they are crucial for Ansible lifecycle. When you are part of a big organization managing virtual environments could be a pain, especially if you have a dozen of projects what require different modules and plugins. For sure Red Hat Ansible Automation Platform 2.x introduce lots of benefits thanks to execution environments (they can run as containers), but I believe it will take some time before organizations will move to AAP 2.x

The reason for this article is to show an example of how Tekton can be used to lifecycle Ansible Tower and Python virtual environments on OpenShift.

Process overview

As we live in the beautiful world of GitOps, therefore the best and easiest way to store our environments would be GIT (GitLab, GitHub, BitBucket, gitea or any other preferred SCM). Each time when developers update their dependencies they follow the standard PullRequest procedure. After changes merged in master branch, Git can trigger Tekton WebHook to launch a pipeline, or it can be triggered manually.

This is a simple version of the pipeline to demonstrate the approach, therefore there is no“testing” stage that is essential for [pre]production pipelines.

There are 4 steps in the pipeline:

Get images and push to local. On this step tekton checkout images from Red Hat Container registry and push them to on-cluster registry.
Download environment. This step checkout virtual environments from a remote git repository and save them on local storage linked with Pipeline
Get Image; Customize image; Push Image. Task checkout image from on-cluster registry, run it in “editable” mode, install additional python environments via Buildah toolchain, saves(commit) image and push it to on-prem registry
Deploy Custom Image. In this step, Tekton downloads Ansible Installer from Red Hat Portal. Effectively Ansible Installer is Ansible playbook that accepts extra parameters via -e keys. Therefore Tekton builds Ansible commands with a few extra -e keys and runs deployment. This step requires namespace admin privileges.

Deploying pipeline

I use OCP 4.6 with pipelines 1.2.3 and assume it’s all up and running.
Create a new project/namespace

oc new-project tower

Tekton creates a services account in each namespace, but as we use the tower installer, it needs extra privileges to create role bindings. Just for the demo, I add tekton SA to cluster-admin group. Please do not do it on prod cluster. Instead, create proper SA or tweak Tekton SA for your namespace.

oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:tower:pipeline

Now we are good to go to deploy tekton pipeline and tasks via kustomize:

$ oc apply -k https://github.com/mancubus77/tekton-ansible-lifecycle.git -n tower

configmap/ansible-inventory unchanged
pipeline.tekton.dev/ansible-build unchanged
task.tekton.dev/ansible-lifecycle configured
task.tekton.dev/buildah configured

Kustomize has a few manifests:
configmap/ansible-inventory — config map for ansible installer. It’s Ansible inventory file that has all key values for deployment.

pipeline.tekton.dev/ansible-build- Tekton pipeline to customize image and deploy Ansible on OpenShift

task.tekton.dev/buildah- Tekton task to customize Red Hat Tower image and add python virtual environments

task.tekton.dev/ansible-lifecycle- Tekton task to deploy Ansible on openshift via the installer

After manifest deployment, you should see pipeline in OpenShift UI:

Ansible builder pipeline in OpenShift UI

The pipeline has a few parameters with default values:

Running deployment

There are a few ways to trigger Tekton pipeline. WebHook — most advanced method when it will be launched Git action like (merge or commit); Pipeline UI in Openshift; Tekton CLI tool tkn (my preference)

In our example, first, we install Ansible Tower 3.8.1 and upgrade it to 3.8.3 later. To trigger first pipeline with default parameters simply run:

tkn pipeline start ansible-build -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/01_pipeline/03_persistent_volume_claim.yaml

I use “Persistent storage template” which created PV and PVC to store tekton artifacts. If all is good you should see the following output
Happy path output looks like this:

Happy Path Output after Pipeline trigger

The result of execution can be seen in UI

After pipeline completer, you should see Ansible Tower deployed in tower namespace.

Ansible Tower version and new environments (Sure you need to apply Tower Subscription on the first login)

Upgrading version or virtual environment

As most of the parameters can be passed to Tekton as parameters on launch, we can easily re-run pipeline with a few arguments. As we agreed before, we are going to deploy a new version of Ansible Tower and keep the same virtual environments. Simply trigger new build:

tkn pipeline start ansible-build \
-p tower-image=3.8.3 \
-p ansible-installer=https://releases.ansible.com/ansible-tower/setup_openshift/ansible-tower-openshift-setup-3.8.3-1.tar.gz \
-w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/01_pipeline/03_persistent_volume_claim.yaml

After pipeline completer, you should see Ansible Tower deployed in tower namespace.