wiki/Catalogue-Self-Hosted/apps/app-ara.md

---
title: ARA Records Ansible
created: 2026-06-07
updated: 2026-06-07
type: app
tags: [catalogue, automation, ansible, reporting, devops, python, django]
confidence: high
contested: false
sources: [https://selfh.st/apps/?tag=Automation, https://github.com/ansible-community/ara]
---

# 📊 ARA Records Ansible

> **Le tableau de bord qui manque à vos playbooks Ansible** — enregistre chaque exécution dans une base consultable (SQLite, MySQL ou PostgreSQL) et expose une UI web, une CLI et une API REST pour comprendre ce qui s'est passé en local comme en CI/CD.

## 📋 Informations Générales

| Champ | Valeur |
| :--- | :--- |
| **Site web** | [ara.recordsansible.org](https://ara.recordsansible.org/) |
| **GitHub** | [ansible-community/ara](https://github.com/ansible-community/ara) |
| **License** | GPL-3.0 |
| **Langage** | Python (70 %), HTML, Django |
| **Étoiles GitHub** | 2 000 ⭐ |
| **Dernière MAJ** | 2026-02-24 |
| **Catégorie** | [[cat-automation\|Automation]] |

## 📝 Description

**ARA** (acronyme récursif pour **A**nsible **R**untime **A**nalysis) est né dans la communauté **OpenStack** avant de migrer sous l'égide d'`ansible-community`. Son objectif est simple : **palier le déficit d'observabilité d'Ansible** en capturant l'intégralité des données générées par chaque playbook et en les rendant consultables.

L'installation est élégante. On installe le **plugin de callback** ARA au niveau du même interpréteur Python qu'Ansible, et chaque `ansible-playbook` envoie automatiquement ses résultats vers la base de données ARA — qu'elle soit locale (SQLite, mode le plus simple) ou distante (MySQL/PostgreSQL, pour centraliser les exécutions de plusieurs machines). Quand l'API server tourne, on consulte l'historique complet dans une UI web : durée, hosts affectés, tâches échouées, **diff** des modifications de fichiers `template` ou `lineinfile`, **résultats des modules** avec leur `stdout`/`stderr` complet.

L'un des points forts d'ARA est sa **compatibilité universelle**. Il fonctionne avec `ansible-core`, `ansible`, `ansible-pull`, `ansible-test`, `ansible-runner`, **AWX** et **Automation Controller** (Tower), **Molecule**, **Semaphore**, et capture les exécutions depuis un terminal local, une VM, un conteneur, un **execution environment Ansible Navigator**, ou un runner CI/CD (Jenkins, GitLab CI, Rundeck, Zuul).

Pour les équipes qui gèrent des **flottes hétérogènes**, ARA devient vite indispensable : on remonte les exécutions de plusieurs administrateurs, on a un **filtre par hôte, par playbook, par tag, par statut** (changed/failed/skipped), et on peut générer des **rapports d'incident** en partageant simplement l'URL. La **CLI** (`ara playbook list`, `ara host list`) complète l'UI pour les scripteurs.

## 🚀 Installation

### Option 1 : Sans API server (SQLite local — démarrage rapide)

```bash
python3 -m pip install --user "ansible" "ara[server]"
export ANSIBLE_CALLBACK_PLUGINS="$(python3 -m ara.setup.callback_plugins)"
ansible-playbook playbook.yml
ara-manage runserver   # http://127.0.0.1:8000
```

Idéal pour tester ou pour un usage mono-machine.

### Option 2 : Docker Compose avec API server centralisé

```yaml
# docker-compose.yml
services:
  ara-api:
    image: docker.io/recordsansible/ara-api:latest
    container_name: ara-api
    restart: unless-stopped
    environment:
      - ARA_BASE_DIR=/opt/ara
      - DJANGO_SETTINGS_MODULE=ara.server.settings
      - ARA_ALLOWED_HOSTS=ara.example.com
    volumes:
      - ./ara-data:/opt/ara
    ports:
      - "8000:8000"

  postgres:
    image: postgres:16-alpine
    container_name: ara-db
    restart: unless-stopped
    environment:
      - POSTGRES_DB=ara
      - POSTGRES_USER=ara
      - POSTGRES_PASSWORD=***    volumes:
      - ara-db:/var/lib/postgresql/data

volumes:
  ara-db:
```

Côté client (chaque poste qui exécute Ansible), configurer l'envoi vers l'API :

```bash
pip install ansible ara
export ANSIBLE_CALLBACK_PLUGINS="$(python3 -m ara.setup.callback_plugins)"
export ARA_API_CLIENT=http
export ARA_API_SERVER=https://ara.example.com
ansible-playbook playbook.yml
```

### Option 3 : Podman

L'image `quay.io/recordsansible/ara-api` est l'équivalent officiel pour les utilisateurs Podman/rhcos.

## ⚙️ Configuration

1. **Authentification API** : activer un **token** ou un reverse proxy SSO ([[app-authelia]]) pour restreindre l'accès à l'UI.
2. **Base PostgreSQL** : en production, passer à PostgreSQL via `ARA_DATABASE_ENGINE=django.db.backends.postgresql` et variables d'environnement associées.
3. **Playbook filtering** : configurer `ignore_playbook_parameters` et `ignore_files` pour exclure les données sensibles (mots de passe passés en extra-vars).
4. **Rétention** : configurer un cron qui purge les playbooks de plus de X jours pour limiter la croissance de la base.
5. **AWX/Controller** : ARA est un **callback plugin** ; l'activer au niveau du **AWX Project** ou de l'organisation pour centraliser les exécutions de tous les utilisateurs.
6. **Performance tuning** : désactiver l'enregistrement des modules verbeux (`command`, `shell`) via `ARA_RECORD_TIMING` et `ARA_RECORD_OUTPUT` si la base gonfle trop.

## 🔄 Alternatives

### Open Source
- **Ansible Tower / AWX** — A sa propre UI, mais focalisée orchestration, pas reporting détaillé par tâche
- [[app-semaphore-ui]] — UI web pour Ansible, sans le niveau de détail d'ARA
- [[app-rundeck]] — Orchestration de jobs multi-outils, peut piloter Ansible
- **Ansible-cmdb** — Génère des rapports HTML statiques, pas de base live

### Propriétaires (ce qu'ARA remplace)
- **Ansible Automation Platform (AAP)** — L'offre Red Hat inclut du reporting, mais payante (et 100% upstream open)
- **Datadog Ansible Integration** — Corrélation avec APM/métriques, facturé à l'ingestion
- **Splunk + Ansible Add-on** — Très puissant mais infrastructure lourde

## 🔐 Sécurité

- 🔐 **Activer l'authentification API** avant toute exposition Internet (token, Basic Auth, ou SSO via reverse proxy)
- ⚠️ ARA **enregistre tout le stdout/stderr** des tâches : si un playbook affiche un mot de passe (Ansible ne le devrait pas, mais...), il sera dans la base — utiliser `no_log: true` sur les tâches sensibles
- 🛡️ **HTTPS obligatoire** ([[app-traefik]], [[app-caddy]]) avec HSTS et **ALLOWED_HOSTS** correctement configuré
- 🔑 Les **tokens d'API** doivent être rotés régulièrement
- 🗄️ Chiffrer la base PostgreSQL au repos
- 📜 Purger régulièrement les exécutions pour limiter l'exposition de données
- 🚨 Mettre à jour régulièrement : `pip install -U ara` pour bénéficier des correctifs

## 📚 Ressources

- [Site officiel ara.recordsansible.org](https://ara.recordsansible.org/)
- [Documentation ara.readthedocs.io](https://ara.readthedocs.io/)
- [Démo live](https://demo.recordsansible.org)
- [Image Docker Hub](https://hub.docker.com/r/recordsansible/ara-api)
- [Ansible Galaxy](https://galaxy.ansible.com/recordsansible/ara)
- [IRC #ara sur Libera.chat](https://web.libera.chat/?channels=#ara)
- [Mastodon @ara@fosstodon.org](https://fosstodon.org/@ara)

## Pages Liées
- [[cat-automation]] — Vue d'ensemble de la catégorie
- [[app-ansible]] — Moteur d'orchestration
- [[app-semaphore-ui]] — UI alternative
- [[app-rundeck]] — Orchestration de jobs
- [[app-traefik]] — Reverse proxy HTTPS
- [[app-authelia]] — SSO
- [[securisation-home-lab]] — Bonnes pratiques
- [[recettes-docker-compose]] — Templates Docker