Do you use Ansible? Maybe even in a pipeline or across teams? Chances are high that you might want to track your changes and last runs in a nice overview with ARA. Let's check out the nifty tool and investigate how it can help you with keeping on top.
Ansible is the Open Source automation software for small use cases or entire cloud ecosystems. With just a bit of YAML, you can start to automate your package installations, network configuration or Kubernetes on AWS.
In the past, I wrote a couple of articles about Ansible and also took a look at the ecosystem occasionally. In case you never heard of Ansible, you should start with one of my "Getting Started" articles.
ARA - ARA records Ansible
ARA provides Ansible reporting by recording
ansible-playbook commands regardless of how and where they run. All of this works with a simple callback plugin that can be integrated in your existing content.
Let's dig into ARA. Shall we?
Reasons for ARA
First, let's get this off the shelf. "Why the hell should I use ARA?" And this one is a bit tricky. You don't need ARA to run Ansible or even make your playbooks faster or more secure.
BUT, you will get transparency of what was running when, how it failed and what was changed. This is useful for mere monitoring purposes, but can be helpful for way more:
- compliance audits
- change management
- CI/CD tracking (ex. GitOps)
- self-service portal use cases
- troubleshooting and diagnose
As you can see, it is not mandatory, but helpful in many scenarios. Let's see how this looks like.
Installing the server
If you read my blog on a regular basis, you know that I am running almost everything in containers. Therefore, let's use the container way for ARA, too. The easiest way to spin up an ARA container is:
# With Podman
$ podman run --name api-server --detach --tty \
--volume ara:/opt/ara:z -p 8000:8000 \
# With Docker
docker run --name api-server --detach --tty \
--volume ara:/opt/ara:z -p 8000:8000 \
Well, this is more or less meant for the first test. To set up ARA for production, you should consider using a proper authentication, and other production grade configurations.
For our showcase, this will be sufficient.
You can browse to
ipaddress:8000 to open the ARA web interface, but there is really not a lot to see, yet.
Let's fill this thing with a bit of content.
Now, that ARA is running, we want to see what can be done with it, right?
Well, ARA works the way, that a playbook or any other Ansible command will require a callback to the ARA API server. This might sound complicated, but it is really easy. First, we need to configure Ansible on our control node to use the ARA callback plugin. To avoid some confusion, let's make a proper project with all things needed.
Project directory and installation
Let's create a project directory and install Ansible in a Python virtual environment in this directory.
# Create project directory
$ mkdir myProject
# Change into it
$ cd myProject/
# Create a Python virtualenv
$ python -m venv .venv
# Activate the new virtualenv
$ source .venv/bin/activate
# Install Ansible and ARA plugins
$ pip install ansible ara
Now, we need to create an Ansible configuration that enables and configures the callback plugin properly. To do so, we need to find the ARA callback plugin path and create the
# Find the callback plugin path
$ python3 -m ara.setup.ansible
# Create the config file
$ touch ansible.cfg
The config file requires some content, we just fetched.
api_client = http
api_server = http://localhost:8000
As you can see, this is mostly the content from the command result above. I have added one additional line
bin_ansible_callback, which also sends ad-hoc commands to ARA. Meaning, even a
ansible myHost -m setup will be tracked in ARA.
Before going onward. In case, you don't want to create a config file for the plugins paths, you can control the same with environment variables. ARA comes with a helper for these, too.
# Show how to create environment variables
$ python3 -m ara.setup.env
Now, that this is out of the way, let's actually create a playbook and run it.
A simple playbook
You can execute the playbook on a standard AlmaLinux OS installation.
$ ansible-playbook -K -k -i ipaddress, playbook.yml
And should be able to browse to
ipaddress:9090 afterward to see the Cockpit web interface.
But, you will also be able to see the results of your playbook run in ARA.
You can also check out the Report of a run by clicking on the very left link (Report column).
And investigate single tasks.
Now, that should be enough for a first idea of how ARA works.
And without a server
Well, ARA does not require a running server. For small use cases and local development, you can run everything on your own machine. The ARA project and its developers are working hard to make it easy and work with ARA.
In case you want to try this out, I would love to recommend the official documentation for the same.
So, what to do next? It works, right? Well, in case you consider running ARA in production, I recommend taking a look at the following topics:
Also, you might be interested to add ARA to your CI/CD pipeline. Therefore, you can look at:
Docs & Links
Finally, let me share some links that might be appealing for you.
So, do you need ARA? It depends. If you want to know what your Ansible is doing, how the history of your runs looks like and integrate Ansible in CI/CD or make reporting easier, sure. Go ahead and give it a try.
If you are just running Ansible occasionally for 2 or 3 machines, it might be a bit over the top, but still useful to make your work more visible.
I will use it for sure in the future and get more insights about my work. What about you? Do you already know, or even use ARA? Do you consider using it? What hinders you?