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

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

EE	Taille	ansible-core	Collections clés
`creator-ee:latest`	~1.2 GB	2.18.x	`ansible.posix`, `community.general`, `kubernetes.core`, `community.docker`, `containers.podman` + ansible-lint
`awx-ee:latest`	~900 MB	2.18.x	Collections AWX/Tower, `awx.awx`, plus orienté run
`community-ee-minimal:latest`	~400 MB	2.18.x	Aucune collection autre que `ansible.builtin`

Quand choisir quoi :

Formation, dev : creator-ee, riche, ansible-lint inclus, autocomplete des collections courantes.
AWX self-hosted : awx-ee, par défaut sur AWX, optimisé.
Custom EE production : partir de community-ee-minimal et ajouter uniquement ce dont on a besoin → image la plus petite, surface d'attaque minimale.

`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 ?

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. ✅

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. ✅

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.

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 dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd 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.

À 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.