At Red Hat Consulting we help customers to adopt Red Hat products and technologies and make the most out of them. We believe addressing customer business needs is the best way to increase customer's ROI.
Based on that premise, at Red Hat Consulting we have different consulting offerings such as the Automation Adoption Journey or the Open Innovation Labs Residency that focus on outcomes and not outputs, aligning the technical solution with the customer business needs.
We rely on practices from the Agile world, Devops, Product Development or Domain Driven Design, all of them curated in the Open Practice Library, to achieve the desired outcomes.
In this article we are going to explain how to build Ansible automation execution environments (EEs) automatically, based on different practices such as everything as code and continuous integration on top of OpenShift.
Let's start by understanding EEs:
Automation execution environments are container images on which all automation in Red Hat® Ansible® Automation Platform is run.
They provide a defined, consistent, and portable environment for executing automation, and allow for easier administration of Ansible Automation Platform by the platform administrator.
The best way to build EEs is relying on a new tool provided by Red Hat® Ansible® Automation Platform, the ansible-builder cli. In order to automate the build of EEs, we make use of OpenShift Pipelines as well.
In this article we will be working with two code repositories:
- https://github.com/jtudelag/ansible-execution-environments/tree/v0.1: Ansible execution environment code can be found here.
- https://github.com/jtudelag/ansible-ee-gitops/tree/v0.2: OpenShift Pipelines (Tekton) manifests can be found here.
The idea is that every time we make a change to the Ansible EE repo, this will trigger the OpenShift Pipeline to build and push the EE to our registry, in this case quay.io.
NOTE: Please check Trigger Pipeline Execution From GitHub article for more details on how OpenShift Pipelines works.
Applying OpenShift Pipelines Manifests
We need to clone the OpenShift Pipelines manifests repo and apply them to the OpenShift cluster. But first we need to create the secrets to pull & push images to the registries and the GitHub webhook secret.
Create Secrets
NOTE: As this example is consuming images from registry.redhat.io and pushing to quay.io, I recommend you use your Red Hat pull secret. You can get it from console.redhat.com.
For the sake of security, the secrets are not included in the repo, we need to create them manually.
First create the project.
oc new-project ansible-ees
Then create the pull & push secret. Replace the secret data with your registry credentials!.
cat << EOF > pull-and-push-secret.yaml
apiVersion: v1
data:
.dockerconfigjson: XXXXXX
kind: Secret
metadata:
annotations:
tekton.dev/docker-0: quay.io
tekton.dev/docker-1: registry.redhat.io
name: pull-and-push
type: kubernetes.io/dockerconfigjson
EOF
oc -n ansible-ees apply -f pull-and-push-secret.yaml
# Link the secret to the pipeline SA, for pulling & pushing
oc secret link pipeline pull-and-push --for=pull,mount
Create GitHub webhook secret.
cat << EOF > github-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: ansible-ee-trigger-secret
type: Generic
stringData:
secretToken: "123"
EOF
oc -n ansible-ees apply -f github-secret.yaml
Apply the ansible-builder Tekton Task
The ansible-builder
Tekton task has been contributed upstream and can be found in Tekton Hub.
Apply it to the cluster in the ansible-ees
namespace.
oc -n ansible-ees apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/ansible-builder/0.1/ansible-builder.yaml
Apply Pipeline Manifests
Now we can clone the Pipeline manifests repo and apply them to the cluster.
git clone --branch v0.2 https://github.com/jtudelag/ansible-ee-gitops.git
cd ansible-ee-gitops
Edit the Trigger Template listener/4-trigger-template.yaml
and change the PipelineRun NAME
parameter to set the image repository name.
NOTE: Remember the parameter TAG
is extracted from the webhook payload, so don't need to touch it.
- apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
annotations:
labels:
tekton.dev/pipeline: ansible-builder
generateName: ansible-ee-triggered-run-
spec:
params:
- name: ANSIBLE_BUILDER_IMAGE
value: >-
registry.redhat.io/ansible-automation-platform-21/ansible-builder-rhel8:1.0.1-47
- name: NAME
value: XXXXXXXXXX
Apply the Pipeline related manifests.
oc -n ansible-ees apply -f listener/
persistentvolumeclaim/ansible-builder-pvc created
pipeline.tekton.dev/ansible-builder created
triggerbinding.triggers.tekton.dev/ansible-ee-tb created
triggertemplate.triggers.tekton.dev/ansible-ee-tt created
trigger.triggers.tekton.dev/ansible-ee-t created
eventlistener.triggers.tekton.dev/ansible-ee-el created
route.route.openshift.io/ansible-ee-el created
This will create the following manifests in the ansible-ees
namespace.
listener/
├── 0-pvc.yaml
├── 2-pipeline-ansible-builder.yaml
├── 3-trigger-binding.yaml
├── 4-trigger-template.yaml
├── 5-trigger.yaml
├── 6-event-listener.yaml
└── 7-el-route.yaml
Basically we have created the Tekton Pipeline and the Trigger & EventListener objects to be able to trigger the Pipeline on certain events, usually webhooks.
The pipeline is very simple, it contains just four steps (tasks):
- Fetch code.
- Build EE context with the ansible-builder tool. (using
ansible-builder
Tekton Hub task) - Build and push the container image tagged with the commit
SHA256
id. - Build and push the container image tagged with
latest
.
We can visually check the Pipeline details in the OpenShift console.
Fork the EE Code Repository
Got to the EE code repository and fork it, so then you can change the repository webhook settings.
Creating GitHub Webhook
As we want to automate the whole process, we are relying on the Trigger & Listener capabilities of OpenShift Pipelines. Every time we commit something to the forked EE repo in GitHub, this will trigger a webhook that will call the EventListener and trigger the Pipeline with the right parameters, some of them extracted from the webhook payload.
We need to configure such a webhook in Github to point to the URL of the EventListener. We can get the EventListener route URL running the following command.
oc -n ansible-ees get route ansible-ee-el -o jsonpath="{.spec.host}"
Now go to your recently forked repo in Github, to Settings
-> Webhooks
-> Add webhook
and create a new webook.
Set the following settings:
- Payload URL: EventListener URL obtained above. Don't forget to add http or https to it.
- Content type: application/json
- Secret: Set it accordingly to the OpenShift secret referenced in the Trigger object. In this case is a dummy "123" string.
Now we just need to make a commit to the forked EE code repo and see how the pipeline is being triggered ;).
Triggering the Pipeline on every commit
We can easily simulate a change in the code by committing a empty change to your forked repo:
git clone https://github.com/<YOUR_FORK>/ansible-execution-environments.git
cd ansible-execution-environments
git commit --allow-empty -m "Empty commit, trigger the pipeline!"
git push origin main
This will trigger the Pipeline and as result produce a PipelineRun object, which is an instance of a Pipeline properly parametrized with all the input parameters required.
Some of those parameters are gathered from the Github webhook payload. You can inspect the TriggerBinding and the Trigger objects for more details.
We can see that the commit id 4242b3f
matches the tag of the image built and pushed to https://quay.io/repository/jtudelag/ansible-ee-test:4242b3f.
We can also see that the latest
tag has been updated as well in quay.io.
Finally we can go to the Openshift console and verify the PipelineRun has succeeded, meaning all the tasks of the Pipeline finished ok!
Conclusion
In this article we have demonstrated how Red Hat Consulting can help you make the most out of Red Hat products like Red Hat® Ansible® Automation Platform and Red Hat® OpenShift® to achieve your business outcomes leveraging on the curated set of Open Practices.
Ask an expert! Need help to get it done faster together? Contact hello-labs-emea@redhat.com.
About the author
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit