Spotlight - ARA records Ansible
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.
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
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 and 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 \
docker.io/recordsansible/ara-api:latest
# With Docker
docker run --name api-server --detach --tty \
--volume ara:/opt/ara:z -p 8000:8000 \
docker.io/recordsansible/ara-api:latestWell, 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.
Running playbooks
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
Configuration
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 ansible.cfg file.
# Find the callback plugin path
$ python3 -m ara.setup.ansible
[defaults]
callback_plugins=/very/long/path/to/ara/plugins/callback
action_plugins=/very/long/path/to/ara/plugins/action
lookup_plugins=/very/long/path/to/ara/plugins/lookup
# Create the config file
$ touch ansible.cfgThe config file requires some content, we just fetched.
[defaults]
bin_ansible_callbacks=True
callback_plugins=/very/long/path/to/ara/plugins/callback
action_plugins=/very/long/path/to/ara/plugins/action
lookup_plugins=/very/long/path/to/ara/plugins/lookup
[ara]
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
export ANSIBLE_CALLBACK_PLUGINS=${ANSIBLE_CALLBACK_PLUGINS:-}${ANSIBLE_CALLBACK_PLUGINS+:}/very/long/path/to/ara/plugins/callback
export ANSIBLE_ACTION_PLUGINS=${ANSIBLE_ACTION_PLUGINS:-}${ANSIBLE_ACTION_PLUGINS+:}/very/long/path/to/ara/plugins/action
export ANSIBLE_LOOKUP_PLUGINS=${ANSIBLE_LOOKUP_PLUGINS:-}${ANSIBLE_LOOKUP_PLUGINS+:}/very/long/path/to/ara/plugins/lookup
export PYTHONPATH=${PYTHONPATH:-}${PYTHONPATH+:}/very/long/path/python
Now, that this is out of the way, let's actually create a playbook and run it.
A simple playbook
Well, let's do something simple, yet interesting. Let's deploy a powerful container platform, including Cockpit and Podman on an AlmaLinux OS 9 machine.
- name: "Deploy Container Platform"
hosts: "all"
tasks:
- name: "Install Podman & Cockpit"
ansible.builtin.package:
name:
- "cockpit"
- "podman"
- "cockpit-podman"
state: "present"
become: true
- name: "Start & Enable Podman Socket"
ansible.builtin.service:
name: "podman.socket"
state: "started"
enabled: true
become: true
- name: "Start & Enable Cockpit Socket"
ansible.builtin.service:
name: "cockpit.socket"
state: "started"
enabled: true
become: true
- name: "Open Firewall for Cockpit"
ansible.posix.firewalld:
service: "cockpit"
state: "enabled"
immediate: true
permanent: true
become: trueplaybook.yml
You can execute the playbook on a standard AlmaLinux OS installation.
$ ansible-playbook -K -k -i ipaddress, playbook.ymlAnd 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.
Next Steps
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.
ansible-communityARA Repository
ARA Documentation
ARA Blog
ARA Demo instance
Conclusion
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?
