Comment ça marche

Les éléments d’une installation, ce qui se passe lors d’un lancement, et où les données sont conservées

  1. Architecture
    1. Technologies utilisées
  2. Ce qui se passe quand vous lancez un formulaire
  3. Où les choses sont stockées

Architecture

AnsibleForms est un serveur Node.js qui sert l’application web et une API REST, adossé à une base de données MySQL. Il lit les formulaires depuis des fichiers YAML et n’exécute rien lui-même : il confie chaque job à un runner. Un playbook part vers l’un de vos conteneurs RTE (runtime environment, environnement d’exécution), qui exécute ansible-playbook, et un modèle ou un job part vers AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins :

Architecture d'AnsibleForms Le navigateur et un client MCP optionnel communiquent avec le serveur AnsibleForms. Le serveur stocke ses données dans MySQL et dans le dossier persistant, et se connecte aux sources de données, aux coffres de secrets, aux dépôts git, aux fournisseurs de connexion, aux canaux de notification, aux serveurs syslog et à un fournisseur de modèles optionnel. Ses runners confient chaque playbook à l'un d'un ou plusieurs conteneurs RTE, chacun via un WebSocket, qui exécutent ansible-playbook et renvoient la sortie au serveur, et chaque modèle ou job à AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins. Navigateur formulaires, concepteur, jobs, chat Client MCP optionnel Serveur AnsibleForms Node.js / Express Application web, API REST Formulaires, expressions Workflows, planifications Serveur MCP (optionnel) Runners confient chaque job à son runner Sources de données bases, API REST, fichiers Coffres de secrets HashiCorp Vault, CyberArk Dépôts git formulaires, playbooks, config Authentification LDAP, Entra ID, OIDC Canaux de notification mail, Slack, Teams, webhooks Serveurs syslog le journal, la piste d'audit Fournisseur de modèles optionnel, assistant de chat Dossier persistant config, formulaires, playbooks MySQL / MariaDB jobs, utilisateurs, identifiants Conteneurs RTE lancent ansible-playbook AWX / AAP / Ascender Semaphore, Rundeck, Jenkins playbooks, WebSocket modèles, jobs

Chaque composant du schéma a son propre rôle :

Composant Rôle
Navigateur L’application web Vue : les formulaires, le Concepteur, l’historique des jobs et les paramètres
Serveur AnsibleForms Évalue les formulaires, enregistre les jobs, exécute les workflows et les planifications, confie chaque job à son runner et le suit, et sert l’API REST
Runners Là où les jobs s’exécutent, ajoutés sous Connexions > Runners : un formulaire en nomme un avec runner: <name>, ou utilise le runner par défaut de son type (voir Runners)
Conteneurs RTE Un ou plusieurs conteneurs d’environnement d’exécution, le même serveur démarré avec AF_ROLE=rte : chacun exécute ansible-playbook pour les formulaires ansible, avec les bibliothèques python et les collections de son image, et renvoie la sortie et le statut final au serveur via un WebSocket, sans identifiants de base de données (voir Comment le RTE s’exécute)
AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins Les runners des modèles et des jobs : les formulaires AWX lancent un modèle de job ou de workflow, les formulaires Semaphore, Rundeck et Jenkins lancent l’un de leurs jobs, et le serveur suit sa sortie
MySQL / MariaDB Contient les jobs et leur sortie, les utilisateurs, les identifiants et les connexions ; seul le serveur la lit et l’écrit
Dossier persistant Contient config.yaml, les fichiers de formulaires, les playbooks, les journaux et les sauvegardes
Sources de données Alimentent les champs : requêtes de base de données, API REST, fichiers et autres fonctions
Coffres de secrets Fournissent l’utilisateur et le mot de passe d’un identifiant au moment de son utilisation, voir Coffres de secrets
Dépôts git Gardent les formulaires, les playbooks et config.yaml sous contrôle de version
Fournisseurs de connexion Connectent les utilisateurs : LDAP, Entra ID et OIDC, en plus des utilisateurs locaux
Canaux de notification Transportent les notifications et les demandes d’approbation : mail, Slack, Microsoft Teams, Telegram ou un webhook
Serveurs syslog Reçoivent le journal et la piste d’audit au fur et à mesure de leur écriture, voir Syslog
Client MCP, chat Optionnels, tous deux désactivés par défaut : le serveur MCP et l’assistant de chat, qui a besoin d’un fournisseur de modèles

Par défaut, un seul conteneur fait tourner ensemble le serveur, l’application web et le travail en arrière-plan, à côté d’un RTE. Pour plusieurs nœuds d’application derrière un répartiteur de charge, un worker qui s’occupe du travail en arrière-plan, et davantage de RTE, voir Mise à l’échelle.

Technologies utilisées

Le serveur et l’interface web reposent sur ces composants :

Élément Technologie
Serveur Node.js et Express
Base de données MySQL ou MariaDB
Interface web Vue 3, avec Bootstrap 5 et Font Awesome

Ce qui se passe quand vous lancez un formulaire

Un lancement passe par les mêmes étapes, qu’il vienne du navigateur ou de l’API REST :

  1. Chargement : le serveur n’envoie que les formulaires que les rôles de l’utilisateur autorisent, et évalue les expressions côté serveur
  2. Envoi : le navigateur transforme les valeurs des champs en extravars et les poste sur POST /api/v2/job
  3. Vérification : le serveur recharge le formulaire pour les rôles de l’utilisateur et, avec la validation au lancement activée, vérifie les valeurs
  4. Enregistrement : le job est stocké avec le statut running, et son id est ajouté aux extravars sous __jobid__
  5. Approbation : un formulaire avec un point d’approval attend qu’un approbateur accepte le job
  6. Identifiants : pour un playbook, l’application (jamais le RTE) lit les identifiants du formulaire dans la base de données ou dans un coffre de secrets
  7. Exécution : le job part vers son runner, celui que le formulaire nomme avec runner: ou celui par défaut de son type. Pour un playbook, l’application envoie le job à son RTE via le WebSocket du RTE, avec ses identifiants scellés pour lui, et le RTE exécute ansible-playbook (voir Comment le RTE s’exécute), et AWX, AAP, Ascender, Semaphore, Rundeck ou Jenkins exécute un modèle ou un job. Un workflow exécute ses nœuds, chacun comme un job à part sur son propre runner
  8. Suivi : le serveur enregistre la sortie dans la base de données au fur et à mesure qu’elle arrive, envoyée par le RTE via son socket pour un playbook, ou lue depuis les autres runners. La page du formulaire relit le job toutes les deux secondes, et la page Jobs le suit en direct à mesure que le serveur annonce chaque changement
  9. Fin : le job reçoit son statut final, et ses notifications partent par mail et vers ses canaux de notification quand le formulaire les demande

Où les choses sont stockées

AnsibleForms conserve son état à deux endroits : la base de données MySQL et le dossier persistant. Sauvegardez les deux.

Dans la base de données

La base de données, AnsibleForms, est créée au premier démarrage (sauf si ALLOW_SCHEMA_CREATION vaut 0) et contient :

  • les jobs, leurs extravars et leur sortie, les planifications et les jobs enregistrés
  • les utilisateurs locaux, les groupes et les jetons d’API
  • les identifiants, chiffrés avec ENCRYPTION_SECRET, et les connexions aux coffres de secrets
  • les runners, les canaux de notification (mail compris), les serveurs syslog, et les paramètres LDAP, SSO, des dépôts et de l’assistant de chat
  • le journal d’audit

Dans le dossier persistant

C’est /app/dist/persistent dans l’image et server/persistent depuis les sources ; chaque chemin a sa propre variable :

Chemin par défaut Variable Contenu
config.yaml CONFIG_PATH Les catégories, les rôles et les constantes
forms/ FORMS_FOLDER_PATH Les fichiers de formulaires, .yaml ou .yml, dans des sous-dossiers si vous le souhaitez
playbooks/ ANSIBLE_PATH Les playbooks des formulaires ansible, et leur répertoire de travail
repositories/ REPO_PATH Les clones des dépôts git
forms_backups/ FORMS_BACKUP_PATH Les copies que le Concepteur fait avant d’enregistrer
backups/ BACKUP_PATH Les sauvegardes de la base de données
uploads/ UPLOAD_PATH Les fichiers téléversés via les champs file
logs/ LOG_PATH ansibleforms.log et ansibleforms.errors.log
certificates/ HTTPS_CERT, HTTPS_KEY Le certificat et la clé, quand HTTPS vaut 1
.env   Les variables d’environnement enregistrées depuis les pages de paramètres (sauf si ALLOW_ENV_EDIT vaut 0)

La clé SSH générée se trouve dans HOME_PATH, hors du dossier persistant par défaut.