Most useful development tool for Ansible content that is rarely used is even better for the teams

Project Discussions Collection Development
,
1

Recently I had a pleasure of presenting at CfgMgmtCamp 2025.

Below is abstract, you can find all talk materials at bit.ly/ara-ansible

"
ARA (ARA Records Ansible) is an Ansible development tool that makes it much easier to understand, troubleshoot and debug Ansible content during development process. This tool can also help you to collaborate with your team members on Ansible content development.

This talk will cover the following topics:

  • What is ARA and how it works
  • How to set up ARA in your environment
  • How to use ARA to understand, troubleshoot and debug Ansible content
  • How to use ARA to collaborate with your team members on Ansible content development
  • How to integrate ARA into your CI/CD pipeline
  • How to use ARA to track changes in your Ansible content

This talk is designed for Ansible content developers of all levels. Whether you are a seasoned expert or just starting with Ansible,
"

Any feedback positive or negative is welcome.

7 Likes
2

We are using it for years now to debug our GitLab CI/CD deployments. It’s a must-have tool to identify issues without adding debug iterations.

In our team, we’re doing deployments and rollouts often locally from our machines and start using ara exports there too. However, we stopped after a very short time because we were leaking to many secrets from our local environments…

Related to your slides

some one have to pay for the servers

In generall a RPI 4/5 or a 5$ VM is sufficient. There is no need for a 100$ overpriced Cloud setup imho.
In our setup, ARA runs piggyback on our GitLab Server.

4 Likes
3

Agree on the cost comment, but for me it is the way it is.

Do you have maybe some suggestions from your experience how not to expose secrets to ARA?

4

Thanks for sharing! (A small regret that I couldn’t make it to Ghent.)

We’ve been using ARA for a couple of years to help us debug our developments.

In production, we also utilize its API to feed a front-end interface, specifically to provide customized, near-real-time views of jobs in progress on our AAP.

Additionally, we’ve placed an API “proxy” in front of it (using FastAPI) to normalize our endpoints and perform some data transformation.

+---------------------+     +----------+     +----------+     +---------------+
|  Front-end Web      | --> | FastAPI  | --> |   ara    | <---|     AWX       |
|     Interface       |     |          |     |          |     |     AAP       |
+---------------------+     +----------+     +----------+     +---------------+
1 Like
5

I generally deploy it on my Ansible control node as a container :slight_smile: next to no extra cost, especially because I can deploy it with Ansible itself :grin:

And I’ve even had colleagues working on customer sites uncovering weird issues because of the regular logging. So it’s a lifesaver in multiple ways, it helps debugging, but also tracking those pesky users that try to disable all kinds of stuff :wink:

1 Like
6

That is a nice way of deploying ARA, my use case is a bit different. I do not have AWX/AAP at all, running all from console.
But I should have thought about this deployment option - this would be a nice addition to improve my presentation.

Do you have any kind of caching? I was thinking about adding cache in front of ARA - all ARA responses are just html pages that should not change, so they are easy to cache. But we have less than 10 users (just our team), so it does not make much sense.
I wonder if anyone added cache to ARA and what were the results.

Thank you for your feedback, guys!

7

Well, we always deploy a CLI control node (well, we were first with calling it a controller, when AWX was still called Tower :wink: but now, the term controller is just confusing…), which we use to deploy other services, including AAP/AWX, if it’s required in that environment. So we always have a system that can run ARA (we just run it in Podman)