Inspecter un Execution Environment Ansible : images, doc, collections, config

Avant de consommer ou de baser un EE custom dessus, il faut savoir ce qu'il contient. ansible-navigator images ouvre une TUI riche qui détaille la version d'ansible-core, les collections embarquées avec leurs versions, les dépendances Python, les packages système, et même les layers du Containerfile. Cette page passe en revue les 3 EE communautaires majeurs (creator-ee, awx-ee, community-ee-minimal) et explique comment choisir le bon point de départ pour son projet.

À la fin, vous saurez inspecter n'importe quel EE OCI public ou privé, comparer plusieurs EE, et lire la doc d'un module dans le contexte de l'EE plutôt que sur Internet.

Ce que vous allez apprendre

• Inspection TUI avec ansible-navigator images.
• 8 sections d'un rapport d'inspection (info, layers, OS, system, ansible, collections, Python, version).
• Comparer 3 EE communautaires sur version, taille, collections.
• ansible-navigator doc : doc d'un module embarqué.
• Inspection sans pull : skopeo inspect et crane manifest.

Prérequis

• creator-ee:latest, awx-ee:latest et community-ee-minimal:latest pull localement.
• Avoir lu Modes interactifs pour la navigation TUI.

ansible-navigator images, l'inspection complète

ansible-navigator images --eei quay.io/ansible/creator-ee:latest

L'interface TUI affiche 8 sections numérotées :

#	Section	Contenu
0	Image information	ID, taille, registre, tag, date
1	Image layers	Layers du Containerfile multi-stage
2	OS release	UBI 9, RHEL 9, Fedora, version exacte
3	System packages	Output rpm -qa ou dpkg -l
4	Ansible version	ansible --version (core + collections location)
5	Ansible collections	ansible-galaxy collection list formatée
6	Python packages	pip list, toutes les deps Python
7	Python version	Major.minor exact

Glissez pour voir

Tapez le numéro d'une section pour drill-down. Le 6 (Python packages) liste toutes les deps installées, indispensable pour vérifier qu'une collection a bien ses dépendances satisfaites.

Mode CLI, extraction scriptable

Pour un workflow scripté :

# Lister les collections en JSON
podman run --rm quay.io/ansible/creator-ee:latest \
  ansible-galaxy collection list --format json | jq '.[]'

# Version ansible-core
podman run --rm quay.io/ansible/creator-ee:latest \
  ansible --version | head -1

# Lister Python deps
podman run --rm quay.io/ansible/creator-ee:latest \
  pip list --format json | jq '.[].name'

🔍 Observation : ces commandes shell sont utilisables dans la CI pour vérifier qu'un EE contient bien community.kubernetes 5.1.1 avant de pousser un playbook qui en dépend.

Comparer les 3 EE communautaires

Trois images publiques couvrent la quasi-totalité des besoins, et elles se distinguent par ce qu'elles embarquent déjà, pas par leur qualité. Le tableau donne leur nom court ; leur référence complète, celle qu'attend un podman pull, mérite d'être notée car les deux familles ne vivent pas au même registre :

Nom court	Référence complète
creator-ee	quay.io/ansible/creator-ee
awx-ee	quay.io/ansible/awx-ee
community-ee-minimal	ghcr.io/ansible-community/community-ee-minimal

Glissez pour voir

Le troisième est le piège du lot, et beaucoup de tutoriels le donnent encore sur Quay. Le fait vérifiable est celui-ci : le dépôt amont ansible-community/images, qui produit ces deux images, ne publie que sur ghcr.io. Son workflow de publication ne pousse nulle part ailleurs, et son README renvoie vers les paquets GitHub de l'organisation. En regard, le catalogue public du namespace ansible sur Quay, relevé le 2026-09-18, contient bien creator-ee et awx-ee mais ni community-ee-minimal ni community-ee-base.

Ce que vous verrez si vous gardez l'ancienne référence mérite d'être connu, car il égare : Quay répond unauthorized, jamais « introuvable ». C'est la même réponse que pour un dépôt privé, si bien que le message ne permet pas de distinguer les deux cas et n'oriente pas vers la vraie cause, un changement de registre.

Les tags de ghcr.io/ansible-community/community-ee-minimal suivent la version d'ansible-core, 2.21.3-1 pour un ansible-core 2.21.3, et le workflow amont vérifie cette correspondance avant de publier. C'est une propriété commode : le tag dit ce que vous obtenez, ce qu'un :latest ne dit jamais.

Les chiffres ci-dessous sont relevés, pas repris d'une documentation : taille occupée sur le disque après podman pull et version rendue par ansible --version dans l'image, au 2026-09-18, sur le tag latest de chacune. Le téléchargement est plus léger que la taille sur disque, les couches voyageant compressées.

EE	Taille sur disque	ansible-core	Collections clés
creator-ee:latest	888 Mo	2.16.3	ansible.posix, community.general, kubernetes.core, community.docker, containers.podman + ansible-lint
awx-ee:latest	2,69 Go	2.18.17	Collections AWX/Tower, awx.awx, plus orienté run
community-ee-minimal:latest	445 Mo	2.21.3	Aucune collection autre que ansible.builtin

Glissez pour voir

Deux enseignements que ce relevé donne et qu'aucune documentation ne dit. D'abord, awx-ee est de loin la plus lourde, trois fois creator-ee : si vous cherchez une image légère, ce n'est pas celle-là. Ensuite, creator-ee:latest a vieilli, ansible-core 2.16.3 sur une base Fedora 39 : elle reste commode pour découvrir l'outillage, mais ne prenez pas sa version d'ansible-core pour la version courante, et ne diagnostiquez pas un comportement de la 2.21 dedans.

Quand choisir quoi :

• Formation, dev : creator-ee, riche, ansible-lint inclus, autocomplete des collections courantes, en gardant en tête son ansible-core en retard.
• AWX self-hosted : awx-ee, par défaut sur AWX, et la seule des trois qui embarque awx.awx.
• Apprendre à construire un EE : partir de community-ee-minimal et ajouter uniquement ce dont on a besoin, ce qui donne l'image la plus petite et la surface d'attaque la plus faible.

Aucune des trois ne se met en production telle quelle, et ce n'est pas un avis : le dépôt amont l'écrit en toutes lettres pour les images community-ee-*, « maintained by the community and are not supported by Red Hat », « Do not use these images for production! ». Elles sont faites pour le développement, les tests et l'intégration continue. Une base communautaire reste un excellent point de départ dont on s'inspire ou qu'on forke, ce que le dépôt encourage explicitement ; ce qui va en production est votre EE construit et versionné par vous, ou une image sous support éditeur.

Et côté Red Hat. Une organisation sous Ansible Automation Platform dispose d'une quatrième option, absente du tableau parce qu'elle n'est pas publique : registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel9. Cette image ajoute les collections certifiées Red Hat à une base UBI 9 et à un ansible-core supporté, et son intérêt n'est pas technique mais contractuel : c'est la seule combinaison sur laquelle le support éditeur s'engage. Elle exige une souscription active, le registre refusant l'accès anonyme. La variante ee-minimal-rhel9 existe au même endroit, sans les collections certifiées. Sans souscription, l'équivalent reste un EE construit sur community-ee-minimal.

ansible-navigator doc, la doc embarquée

ansible-navigator doc ansible.builtin.copy

TUI riche avec :

• Synopsis du module.
• Paramètres typés (string, bool, list...) avec valeurs par défaut.
• Examples YAML directement copiables.
• Return values (ce que register: capturera).

🔍 Observation cruciale : la doc affichée est celle de la version embarquée dans l'EE. Si votre EE a community.general 9.0.0 mais que la doc internet est sur la 10.x, vous évitez les paramètres qui n'existent pas encore dans votre version.

Mode CLI :

ansible-navigator doc ansible.builtin.copy -m stdout | less

ansible-navigator collections, vue groupée

ansible-navigator collections --eei quay.io/ansible/creator-ee:latest

Liste structurée, plus lisible que la sortie brute de ansible-galaxy collection list. Drill-down possible sur une collection pour voir ses modules, plugins, rôles.

Inspection sans pull, skopeo / crane

Quand pull faire ~1 GB pour vérifier la version est trop coûteux (CI, postes contraints), inspectez sans pull :

# skopeo (livré avec Podman)
skopeo inspect docker://quay.io/ansible/creator-ee:latest

# crane (Google, plus rapide)
crane manifest quay.io/ansible/creator-ee:latest
crane config quay.io/ansible/creator-ee:latest | jq .config.Labels

Vous obtenez le digest, les labels, la taille sans pull les layers. Économie de bande passante massive si on a beaucoup d'EE à comparer.

Cas pratique, choix d'un EE pour un projet K8s

Votre playbook utilise kubernetes.core et community.kubernetes. Question : quel EE prendre ?

1. Vérifier creator-ee :

   podman run --rm quay.io/ansible/creator-ee:latest \
     ansible-galaxy collection list | grep -E 'kubernetes|community'

   → kubernetes.core 5.1.1 présent. ✅

2. Vérifier les Python deps :

   podman run --rm quay.io/ansible/creator-ee:latest \
     pip list | grep -i kubernetes

   → kubernetes 31.0.0 présent. ✅

3. Conclusion : creator-ee suffit pour un projet K8s.

Si rien ne convient : suivre Construire un EE sur mesure avec ansible-builder pour partir de community-ee-minimal et n'ajouter que les collections K8s pinnées.

Mettre en pratique

Comparer des environnements d'exécution sur la foi d'un tableau ne remplace pas l'inspection de leur contenu réel. Le lab automatise cette comparaison avec ansible-navigator images : vous relevez pour chacun la version d'ansible-core, les collections embarquées et la taille, puis vous tranchez pour un cas d'usage donné. La validation porte sur le script d'inspection et sur la cohérence de la décision, pas sur l'environnement finalement retenu.

Lab pratique

Inspecter un Execution Environment et choisir le bon

$ dsoxlab run ee-inspection

Environnement : Shell·Durée : ~30 min

Validé : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run ee-inspection
dsoxlab check ee-inspection

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• ansible-navigator images est l'outil de référence pour inspecter un EE (8 vues).
• 3 EE communautaires : creator-ee (riche), awx-ee (AWX), community-ee-minimal (base custom).
• ansible-navigator doc affiche la doc embarquée dans l'EE, version exacte qui s'exécutera.
• skopeo inspect / crane manifest pour inspecter sans pull.
• Cas K8s, Cloud, Windows : creator-ee couvre déjà beaucoup. Custom EE seulement si nécessaire.
• Avant de baser un EE custom : toujours inspecter ce que la base apporte.

Pour aller plus loin

• Exécution en CI/CD : Automatiser la construction et la publication de l'image que vous savez maintenant inspecter.
• Debug d'un EE cassé : Ce que révèle l'inspection quand ansible-core est absent d'une image pourtant construite.
• Découvrir une collection : Comprendre ce que sont les collections listées par l'inspection, et pourquoi le FQCN est obligatoire.

×

📖 Voir la documentation →