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.

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:latest

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.

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.cfg

The 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: true

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.

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:

• API Security
• Using another Database than SQLite
• Administrate the server

Also, you might be interested to add ARA to your CI/CD pipeline. Therefore, you can look at:

• ARA API client
• Names and Labels

Docs & Links

Finally, let me share some links that might be appealing for you.

GitHub - ansible-community/ara: ARA Records Ansible and makes it easier to understand and troubleshoot.

ARA Records Ansible and makes it easier to understand and troubleshoot. - GitHub - ansible-community/ara: ARA Records Ansible and makes it easier to understand and troubleshoot.

GitHubansible-community

Welcome to the ARA documentation! — ara 1.7.1.dev5 documentation

Blogs

Records Ansible and makes it easier to understand and troubleshoot.

ara

ara | Playbooks: 1-100 of 3887

ARA Records Ansible

Playbooks: 1-100 of 3887

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?