AWX : relancer un job en échec sans rejouer une action partielle

Un job AWX en échec donne souvent une tentation simple : cliquer sur relancer. C’est parfois la bonne décision, mais seulement si l’échec est arrivé avant tout changement ou si le playbook est réellement idempotent. En production, une relance aveugle peut redémarrer deux fois un service, réappliquer une configuration sur un sous-ensemble d’hôtes, écraser une preuve utile ou masquer la cause initiale.

Le cas d’usage est un template AWX de maintenance qui applique une correction bornée sur un groupe de serveurs. Le job échoue au milieu de l’exécution : deux hôtes sont passés en changed, un hôte a échoué, les autres n’ont pas été touchés. L’objectif du runbook est de décider s’il faut relancer tout le job, relancer seulement les hôtes en échec, corriger les variables, déclencher un rollback ou arrêter l’automatisation le temps de relire le playbook.

Geler le contexte avant toute relance

La première action n’est pas de corriger. C’est de préserver l’état du diagnostic. Un job AWX contient déjà beaucoup de preuves : template, inventaire, projet, révision Git, variables de lancement, credential utilisé, événements Ansible et hôtes touchés. Si l’équipe relance trop vite, elle mélange la première panne avec une deuxième tentative.

JOB_ID="12345"

awx jobs get "$JOB_ID" --format json | jq '{id,name,status,failed,started,finished,elapsed,launch_type,inventory,project,job_template,job_explanation,scm_revision,extra_vars}'

awx job_events list --job "$JOB_ID" --format json | jq '.results[] | {counter,event,host:.host_name,task:.event_data.task,changed:.event_data.res.changed,failed:.event_data.res.failed,msg:.event_data.res.msg}' > "awx-job-$JOB_ID-events.jsonl"

Cette capture ne remplace pas l’analyse, mais elle évite de perdre le fil. Elle permet aussi de répondre à une question essentielle : l’échec s’est-il produit avant ou après une action qui a modifié l’état cible ?

Séparer les hôtes modifiés, échoués et non touchés

Un job AWX n’échoue pas toujours de manière uniforme. Un playbook peut réussir sur quelques hôtes, échouer sur un hôte isolé, puis arrêter le reste selon la stratégie Ansible. La décision de relance dépend donc du périmètre réel, pas du statut global rouge.

JOB_ID="12345"

awx job_events list --job "$JOB_ID" --event runner_on_ok --format json | jq -r '.results[] | select(.event_data.res.changed == true) | [.host_name, .event_data.task] | @tsv' | sort -u > changed-hosts.tsv

awx job_events list --job "$JOB_ID" --event runner_on_failed --format json | jq -r '.results[] | [.host_name, .event_data.task, (.event_data.res.msg // .event_data.res.stderr // "no message")] | @tsv' | sort -u > failed-hosts.tsv

awx job_events list --job "$JOB_ID" --format json | jq -r '.results[] | select(.host_name != null) | .host_name' | sort -u > seen-hosts.txt

Trois cas changent la lecture. Si aucun hôte n’a changé, une relance après correction de cause est souvent acceptable. Si certains hôtes ont changé puis échoué, il faut prouver l’idempotence ou limiter la suite. Si les hôtes non touchés sont nombreux, la relance doit éviter de retraiter ceux qui ont déjà appliqué la modification.

Vérifier les variables et la révision exécutée

Une relance AWX doit repartir du même contrat, sauf correction volontaire. Comparez la révision Git, les variables, le credential et l’inventaire. Une panne due à une mauvaise variable ne se traite pas comme une panne réseau temporaire.

Contexte a comparer
Job template identique
Projet AWX et revision Git identifies
Inventaire identique ou relance limitee documentee
Extra vars conservees ou correction explicite
Credential identique ou changement approuve
Execution environment identique
Limite d'hotes documentee si relance partielle

Questions avant relance
Le playbook est-il idempotent sur les taches deja changed ?
Une variable incorrecte a-t-elle cause l'echec ?
Le rollback est-il plus sur qu'une relance ?
La relance doit-elle viser tous les hotes, seulement failed, ou seulement not reached ?

Si une variable change entre deux tentatives, ce n’est plus une simple relance. C’est un nouveau changement opérationnel. Il doit produire sa propre preuve et, si nécessaire, sa propre validation.

Classer la cause avant de choisir l’action

Le statut failed ne suffit pas. Il faut qualifier la famille de panne : erreur de paramètre, hôte injoignable, permission, dépendance externe, tâche non idempotente, bug de rôle ou rupture de prérequis. Chaque famille appelle une réponse différente.

Erreur de parametre
Corriger extra_vars ou survey
Ne pas relancer sans nouvelle validation si le scope change

Hote injoignable
Verifier DNS, SSH, bastion, credential et maintenance window
Relancer seulement les hotes non atteints si aucune tache changed

Permission refusee
Verifier credential AWX et sudoers cible
Ne pas elargir les droits sans preuve du besoin exact

Tache changed puis echec
Prouver idempotence ou preparer rollback
Relance limitee et surveillee

Bug de role ou dependance
Corriger le depot, synchroniser le projet AWX, relancer sur scope borne
Conserver la revision fautive dans le ticket

Cette classification évite deux excès : relancer tout par réflexe ou bloquer toute l’automatisation alors qu’une relance ciblée suffit.

Choisir une relance limitée quand c’est possible

La relance la plus sûre est souvent la plus petite qui restaure l’état attendu. Si un seul hôte a échoué après une dépendance temporaire, inutile de retraiter tout l’inventaire. Si plusieurs hôtes ont déjà changé, relancer uniquement les hôtes en échec limite le risque de double action.

TEMPLATE_ID="42"
FAILED_LIMIT="web03.example.local"

awx job_templates launch "$TEMPLATE_ID" --limit "$FAILED_LIMIT" --extra_vars @approved-extra-vars.yml --monitor

La limite doit être écrite dans le ticket ou la note d’incident. Une relance partielle non documentée devient difficile à expliquer si un contrôle post-action trouve des états divergents entre hôtes.

Valider l’état final, pas seulement le statut vert

Un job relancé qui passe au vert ne prouve pas que l’opération est saine. Il faut vérifier l’effet attendu sur les hôtes déjà modifiés, les hôtes relancés et les hôtes qui n’ont jamais été touchés. Le contrôle dépend du type d’action, mais il doit être explicite.

validation:
changed_hosts:
  - verifier service actif et version attendue
  - confirmer absence de double redemarrage non prevu
failed_hosts_rerun:
  - verifier tache initialement en echec
  - comparer configuration finale avec baseline
untouched_hosts:
  - confirmer absence de changement inattendu
evidence:
  - job initial et job de relance lies dans le ticket
  - revision Git et extra_vars conservees
  - decision de rollback documentee si ecart detecte

La validation doit aussi regarder les effets secondaires : alertes, logs applicatifs, métriques de service, erreurs d’authentification ou files de traitement selon le périmètre du playbook.

Préparer le rollback quand la relance n’est pas sûre

Certaines situations ne doivent pas être relancées. Si une tâche non idempotente a modifié une partie du parc, si les variables étaient fausses ou si le rôle a appliqué une configuration incomplète, le bon mouvement peut être un rollback contrôlé avant toute nouvelle tentative.

Relancer
Aucun changed avant echec
Cause temporaire corrigee
Meme revision et memes variables
Relance limitee possible

Relancer avec validation humaine
Changed partiel mais playbook idempotent
Hote en echec isole
Controle post-action disponible
Fenetre de changement encore ouverte

Rollbacker
Changed partiel non idempotent
Variables incorrectes appliquees
Configuration finale divergente
Impact utilisateur ou monitoring degrade

Arreter et corriger le code
Role defectueux
Precondition manquante
Template trop permissif
Credential ou inventaire incoherent

Le rollback doit être aussi borné que la relance : mêmes hôtes, même preuve, même exigence de validation. Sinon l’équipe remplace une action partielle par une action inverse tout aussi difficile à expliquer.

Conclusion

Relancer un job AWX en échec est une décision d’exploitation, pas un geste d’interface. Avant de cliquer, il faut savoir ce qui a changé, sur quels hôtes, avec quelles variables et quelle révision. Le statut rouge signale un problème ; les événements Ansible disent si la relance est sûre.

La bonne décision est celle qui garde le périmètre explicable : relance complète si rien n’a changé, relance limitée si la cause est isolée, correction de variables si le contrat était faux, rollback si l’état partiel est dangereux. C’est cette discipline qui permet d’utiliser AWX comme un outil d’exploitation fiable plutôt que comme un bouton de répétition risqué.