AWX : valider un inventaire dynamique avant un job de production

Un inventaire dynamique AWX donne une impression de confort : les hôtes viennent de la source réelle, les groupes se mettent à jour, les jobs ciblent moins de fichiers statiques. En production, ce confort devient dangereux si un changement de filtre, de credential ou de variable fait entrer de nouveaux hôtes dans le périmètre sans validation.

Le cas d’usage est classique : une équipe synchronise un inventaire depuis Azure, VMware, une CMDB ou un script interne. Un job de maintenance doit redémarrer un agent, appliquer une baseline ou vérifier une configuration. Avant de lancer le template, l’équipe découvre que la dernière synchronisation a ajouté des hôtes, retiré un groupe ou modifié des variables. Le bon réflexe n’est pas de lancer le job “pour voir”. Il faut qualifier l’inventaire comme une dépendance de production.

L’objectif du runbook est de décider si l’inventaire est sûr pour le job prévu, si la limite d’hôtes doit être resserrée, si la source doit être rollbackée ou si l’exécution doit être bloquée.

Capturer la source avant synchronisation

Avant de cliquer sur sync, identifier ce qui produit l’inventaire : plugin, credential, organisation AWX, projet, fichier de configuration, requête API, tags ou groupes utilisés comme filtres. Un inventaire dynamique n’est pas neutre : il traduit des métadonnées externes en cibles exécutables.

INVENTORY_ID="17"

awx inventories get "$INVENTORY_ID" --format json | jq '{id,name,organization,variables,kind}'

awx inventory_sources list --inventory "$INVENTORY_ID" --format json | jq '.results[] | {id,name,source,credential,source_project,source_path,source_vars,update_on_launch,overwrite,overwrite_vars}'

Deux options méritent une attention particulière. overwrite peut retirer des hôtes absents de la source. overwrite_vars peut remplacer des variables déjà utilisées par les playbooks. Ces deux réglages changent directement le comportement d’un job.

Comparer l’inventaire avant et après

Une synchronisation réussie ne prouve pas que le périmètre est acceptable. Elle prouve seulement que la source a répondu et que AWX a produit une nouvelle vue. Il faut comparer les hôtes et les groupes avant d’exécuter une action.

INVENTORY_ID="17"

awx hosts list --inventory "$INVENTORY_ID" --all --format json | jq -r '.results[] | [.name, (.enabled|tostring), (.variables|tostring)] | @tsv' | sort > hosts-before.tsv

awx inventory_sources update "23" --monitor

awx hosts list --inventory "$INVENTORY_ID" --all --format json | jq -r '.results[] | [.name, (.enabled|tostring), (.variables|tostring)] | @tsv' | sort > hosts-after.tsv

diff -u hosts-before.tsv hosts-after.tsv || true

Le diff doit être lu comme une preuve de changement. Un hôte ajouté peut être normal après un scale-out. Un hôte retiré peut indiquer un tag Azure supprimé, une erreur de CMDB ou un credential qui ne voit plus tout le périmètre.

Vérifier les groupes qui alimentent le job

Un template AWX cible rarement tout l’inventaire. Il cible un groupe, un pattern ou une limite saisie au lancement. Le contrôle utile consiste donc à vérifier les groupes réellement utilisés par le job, pas seulement le nombre total d’hôtes.

JOB_TEMPLATE_ID="42"

awx job_templates get "$JOB_TEMPLATE_ID" --format json | jq '{id,name,inventory,limit,ask_limit_on_launch,extra_vars,job_tags,skip_tags}'

awx groups list --inventory "17" --all --format json | jq -r '.results[] | [.name, .total_hosts] | @tsv' | sort

Si le groupe production_web passe de 12 à 38 hôtes, le sujet n’est pas seulement technique. Le changement modifie le risque opérationnel du job. La décision peut être de lancer avec une limite stricte, de corriger la source ou de créer une fenêtre de changement plus large.

Contrôler les variables et les identités

Un inventaire dynamique ne transporte pas seulement des noms d’hôtes. Il peut injecter ansible_host, ansible_user, des variables de rôle, des tags applicatifs ou des paramètres de connexion. Une variable modifiée peut faire échouer un job ou, pire, le faire réussir sur le mauvais chemin.

Variables a verifier
ansible_host change vers une IP inattendue
ansible_user change vers un compte plus privilegie
groupes applicatifs modifies par tag ou label
variables de role remplacees par overwrite_vars
environnement detecte differe du nom du groupe
hote disabled redevenu enabled sans validation

Identites a verifier
Credential AWX utilise par la source
Credential SSH ou WinRM du job
Droits API de la source externe
Perimetre visible par l'identite apres changement

Le critère de validation n’est pas “l’inventaire se synchronise”. C’est “le job verra les bonnes cibles avec les bonnes variables et les bons credentials”.

Lancer un précontrôle sans effet

Avant un job qui modifie l’état, lancer un précontrôle en lecture seule sur le même périmètre. Ce précontrôle doit confirmer la connectivité, le nombre d’hôtes, l’environnement attendu et les variables critiques.

---
- name: Validate dynamic inventory scope
hosts: "{{ target_group }}"
gather_facts: false
tasks:
  - name: Show resolved target and environment
    ansible.builtin.debug:
      msg: "{{ inventory_hostname }} env={{ env | default('missing') }} ansible_host={{ ansible_host | default('missing') }}"

  - name: Reject missing environment marker
    ansible.builtin.fail:
      msg: "Environment marker is missing"
    when: env is not defined

  - name: Reject production database hosts for this job
    ansible.builtin.fail:
      msg: "This job cannot target production databases"
    when: group_names is search('production_databases')

Ce précontrôle n’a pas besoin de tout tester. Il doit surtout rendre visible le périmètre réellement résolu par AWX. Si le précontrôle surprend l’équipe, le job de production doit être suspendu.

Décider exécution, limite ou rollback

La décision doit être explicite. Un inventaire dynamique peut changer pour de bonnes raisons, mais il ne doit pas élargir silencieusement une action.

Executer
Diff attendu et documente
Groupe cible stable ou changement approuve
Variables critiques inchangees
Precontrole lecture seule vert
Rollback de source identifie

Executer avec limite
Nouveaux hotes legitimes mais non encore valides
Maintenance urgente sur un sous-ensemble connu
Limite ecrite dans le ticket et dans le lancement AWX

Bloquer
Groupe production elargi sans validation
Variables de connexion modifiees
Hote sensible entre dans le perimetre
Source externe incoherente ou credential degrade

Rollbacker l'inventaire
Mauvais filtre de source
Tag ou label externe supprime par erreur
overwrite_vars a remplace des variables stables
La synchronisation retire des hotes critiques

Le rollback peut être un retour à la configuration précédente de la source, une désactivation temporaire de update_on_launch, une limite manuelle ou un retour au commit précédent du projet d’inventaire.

Valider après le job

Après exécution, relier trois preuves : la version de l’inventaire, le job lancé et l’effet observé. Sans ce lien, il devient difficile d’expliquer pourquoi un hôte a été touché ou oublié.

JOB_ID="12345"

awx jobs get "$JOB_ID" --format json | jq '{id,name,status,inventory,limit,scm_revision,extra_vars,started,finished}'

awx job_events list --job "$JOB_ID" --format json | jq -r '.results[] | select(.host_name != null) | [.host_name, .event, (.event_data.task // "")] | @tsv' | sort -u > job-host-events.tsv

Si un hôte attendu n’a pas été touché, ne corrigez pas seulement le playbook. Revenir au diff d’inventaire permet de savoir si le problème vient du scope AWX, de la source externe ou de la limite de lancement.

Conclusion

Un inventaire dynamique AWX est une interface d’exploitation. Il décide quels systèmes deviennent atteignables par un job, avec quelles variables et quels credentials. Le traiter comme une simple liste d’hôtes crée des incidents discrets : bon playbook, mauvais périmètre.

La décision saine est sobre : comparer avant/après, valider les groupes du template, contrôler les variables critiques, lancer un précontrôle en lecture seule, puis exécuter seulement si le périmètre est explicable. Si l’inventaire dérive, le rollback de la source est souvent plus sûr qu’une correction improvisée dans le job.