SecureAnyCloud
Deployment guide

ARA

Overview

ARA Records Ansible (ARA) is an open source, self-hosted reporting tool for Ansible. A lightweight callback plugin captures every play, task, host and result as your playbooks run and sends them to a small API server. The server stores the data and shows it in a web interface backed by a REST API.

Point Ansible at the recorder and run your playbooks as you already do. ARA builds a durable, queryable record of what ran, on which hosts, in what order and what changed. The SecureAnyCloud image serves ARA 1.8.0 behind an nginx reverse proxy on a hardened Ubuntu 24.04 LTS base, patched at build time.

What you get:

  • ARA Records Ansible 1.8.0 served by gunicorn behind nginx, managed by systemd. The Django API and UI application runs under gunicorn on the loopback interface (127.0.0.1:8000), and nginx serves it on port 80.
  • The ARA reporting web UI and the REST API on :80, both requiring authentication
  • Secure by default: read and write access are gated, with no open endpoint. Unlike a manual install, the image exposes no unauthenticated read or write path.
  • No default administrator and no shared password in the image. The first boot of every instance generates a unique administrator credential.
  • A fresh Django application secret key generated on the first boot of every instance
  • Ansible (ansible-core) and the ara callback preinstalled, so the appliance records runs out of the box
  • The application server bound to 127.0.0.1:8000 only, never exposed directly to the network
  • nginx.service and ara-web.service as enabled systemd units
  • 24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point. Size up as your recorded history grows.

In the NSG, allow inbound 22/tcp from your management network and 80/tcp for the reporting UI and API. ARA serves plain HTTP on port 80, so for production, terminate TLS in front of it with your own domain. The application server is never exposed directly. It listens on 127.0.0.1:8000 only, so port 8000 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, and search the Marketplace for ARA Records Ansible by SecureAnyCloud. Choose Create.

On the Basics tab, choose your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80). Then choose Review + create, and then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:ara-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name ara \
  --image sac1647283583153:ara-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 80 for the reporting UI and API:

az vm open-port --resource-group <your-rg> --name ara --port 80

Step 3 - Confirm the services are running

SSH in as azureuser and confirm that nginx and the ARA application are active. The application server listens only on 127.0.0.1:8000, while nginx serves the UI and API on port 80.

systemctl is-active nginx ara-web

Check the installed version, and confirm that gunicorn is bound to loopback only:

/opt/ara/venv/bin/python -c "from ara.setup import ara_version as v; print('ARA', v)"

Step 4 - Confirm secure by default and retrieve your admin credential

The image is secure by default. The liveness endpoint is open and answers without authentication. The reporting UI and the REST API return 401 until you present the per-instance administrator credential. Confirm this:

curl -s -o /dev/null -w 'GET /healthcheck/ -> HTTP %{http_code}\n' http://127.0.0.1/healthcheck/
curl -s -o /dev/null -w 'GET / (no auth) -> HTTP %{http_code}\n' http://127.0.0.1/

A 401 on / confirms that there is no open read or write path. The first boot generated your unique administrator credential and wrote it to a root-only file. Read it over SSH:

sudo cat /root/ara-credentials.txt

Step 5 - Sign in to the reporting UI

Browse to http://<vm-public-ip>/. Your browser prompts for a username and password. Enter the ara.username and ara.password from the credentials file.

The reporting UI opens on the Playbooks page. It lists every recorded Ansible run with its status, duration, controller, and host, task and result counts.

Step 6 - Record a playbook run

The appliance is preconfigured to record into the local ARA server. The file /etc/ara/ansible.cfg enables the ara callback and points it at http://127.0.0.1. View the file:

cat /etc/ara/ansible.cfg

A helper on the appliance runs a small demo playbook through the ara callback. It then reads the record back through the authenticated API to prove the end-to-end round trip. Run the helper:

sudo /usr/local/sbin/ara-record-check.sh

Step 7 - Explore a recorded run

On the Playbooks page, choose any run to open its detail. The detail shows the execution metadata, the Ansible, ara and Python versions, a summary of hosts, tasks, results, plays and files, and the full task results below.

The Tasks page lists every recorded task across your runs, with its action, name, path and status. You can see at a glance which task failed on which host.

The Hosts page summarizes the hosts that appeared in your runs and the results recorded against each.

Step 8 - Point your own Ansible control node at ARA

To record runs from a control node elsewhere, install ARA's client in that environment and enable the callback. Then set the API client to HTTP and point it at this appliance with your administrator credential:

pip install ara export ANSIBLE_CALLBACK_PLUGINS="$(python3 -m ara.setup.callback_plugins)" export ANSIBLE_CALLBACKS_ENABLED=ara_default export ARA_API_CLIENT=http export ARA_API_SERVER=http://<vm-public-ip> export ARA_API_USERNAME=ara export ARA_API_PASSWORD=<the ara.password from /root/ara-credentials.txt> ansible-playbook your-playbook.yml

ARA records each later ansible-playbook run, and the run appears immediately in the reporting UI. To add more users, or to scope read and write access per user, use the Django admin at /admin/ or run sudo /usr/local/sbin/ara-manage createsuperuser.

Security notes

  • ARA serves plain HTTP on port 80. For production, put it behind your own TLS-terminating reverse proxy or an Azure Application Gateway with a certificate for your domain, and restrict port 80 in the NSG to trusted networks. A common approach is certbot with your-domain on a front-end proxy.
  • The reporting UI and the REST API both require authentication, so there is no unauthenticated read or write path. Only the /healthcheck/ liveness endpoint, which reports up or down status only, is open.
  • The application server listens on 127.0.0.1:8000 only and is never exposed directly. Only nginx on port 80 faces the network.
  • The image ships with no administrator and no shared password, and no application secret key is baked into it. The first boot of every instance generates a fresh secret key and a unique administrator credential, and writes them to a root-only file. There are no default credentials to rotate.
  • Keep the VM patched. The image is patched at build time and ships with unattended security upgrades enabled.

Support

SecureAnyCloud images come with 24/7 support. If you have questions about this ARA Records Ansible image or need help with your deployment, contact us through the SecureAnyCloud website.

Deploy on Azure

Launch ARA Records Ansible on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure