Aller au contenu

Automatiser l'exécution — AutomationRiver

InfraRiver décide quand, votre outil d'automatisation exécute. AutomationRiver déclenche un job Jenkins, un pipeline GitLab CI ou un Job Template AWX / Ansible Tower au démarrage d'une fenêtre de patching — ou à la demande. Il ne se substitue jamais à votre chaîne d'exécution et n'obtient aucun droit qu'elle n'a déjà.

Page : Connecteurs → AutomationRiver (/plugins/automationriver/).

Principe : backends et actions

Objet Ce que c'est Exemple
Backend Une connexion à un outil d'automatisation « Jenkins prod », https://jenkins.interne
Action Un job précis à lancer sur un backend, dans un contexte donné « Patch Linux prod » → job infra/patch-linux, au démarrage des fenêtres, environnement prod

Un backend peut porter plusieurs actions. Chaque backend et chaque action peut être désactivé sans être supprimé.

1. Déclarer un backend

Champ Description
Nom du backend Libellé libre
Type jenkins, gitlab ou awx (AWX et Ansible Tower partagent la même API)
URL URL de base de l'outil
Utilisateur Compte technique (Jenkins)
Token Jeton d'API / de déclenchement — stocké chiffré, jamais réaffiché
Vérification SSL Activée par défaut. La désactiver est explicite et journalisé en avertissement
Timeout (secondes) Délai maximal d'un appel (30 par défaut)

La colonne Santé teste la connexion (appel limité à 5 secondes, pour ne jamais bloquer la page si l'outil est indisponible).

2. Créer une action

Champ Description
Nom Libellé libre
Backend Le backend qui exécutera le job
Déclencheur Démarrage fenêtre patching (automatique) ou Manuel (bouton uniquement)
Référence du job Voir le tableau ci-dessous
Filtre environnement Limite l'action aux serveurs d'un environnement (prod, preprod…). Vide = tous
Paramètres Paramètres transmis au job, au format propre à chaque outil

Référence du job et paramètres selon l'outil

  • Référence : chemin du job, ex. infra/patch-linux
  • Paramètres : un objet plat, transmis comme paramètres de build
{"HOSTNAME": "srv01", "ENV": "prod"}
  • Référence : id_projet:branche, ex. 42:main
  • Le trigger token GitLab est un secret : il va dans le token du backend, jamais dans la référence
  • Paramètres : variables de pipeline
{"variables": [{"key": "TARGET", "value": "srv01"}]}
  • Référence : identifiant numérique du Job Template, ex. 17
  • Paramètres : extra_vars Ansible
{"extra_vars": {"target_host": "srv01"}}

3. Déclenchement

À l'heure de début de chaque fenêtre de patching, InfraRiver notifie d'abord les abonnés, puis lance les actions actives dont le filtre d'environnement correspond au serveur.

Aucun double déclenchement : chaque couple (action, serveur, fenêtre) ne peut être lancé qu'une fois, même si le service redémarre au mauvais moment ou rattrape une exécution manquée. Une tentative en double apparaît dans le journal avec le statut skipped.

Le bouton de déclenchement lance l'action immédiatement, résultat affiché sur la page. Pas de protection anti-doublon : cliquer, c'est vouloir relancer.

4. Journal d'exécution

Chaque déclenchement est journalisé : action, serveur, déclencheur, statut, lien vers le run dans l'outil, date.

Statut Signification
pending Déclenchement réservé, appel en cours
success L'outil a accepté le job
failure L'outil a refusé l'appel ou est injoignable
timeout Pas de réponse dans le délai du backend
skipped Doublon évité (même action, même serveur, même fenêtre)

Ce que « success » veut dire

success signifie que le job a été lancé, pas qu'il a réussi. InfraRiver ne suit pas l'avancement du job : c'est le rôle de votre outil d'automatisation — suivez le lien du run. Il n'y a pas non plus de nouvelle tentative automatique après un échec : relancez manuellement après correction.