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 : passer au lab ee/builder-custom pour builder un EE custom basé sur community-ee-minimal + collections K8s pinnées.

Lab pratique

Le lab ee/inspection (labs/ee/inspection/) automatise la comparaison des 3 EE avec un script inspect.sh et 4 tests pytest.

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

Prochaines étapes

Construire son EE custom execution-environment.yml v3, ansible-builder, multi-stage avec Podman.

Pipeline CI/CD EE GitHub Actions + GitLab CI : build, scan Trivy, push, cosign keyless.

Lab 85 sur GitHub Inspection comparée des 3 EE communautaires avec tests pytest.