Execution Environments Ansible : ansible-navigator, ansible-builder, EE custom

Un Execution Environment (EE) est une image conteneur OCI qui empaquette tout ce dont Ansible a besoin pour tourner : ansible-core, ansible-runner, des collections Galaxy, des dépendances Python et des packages système. Le même runtime tourne du laptop de dev au controller AAP, en CI, sur AWX self-hosted. C'est la fin du « ça marche sur mon poste » et la base de la reproductibilité Ansible 2026. Cette section couvre l'adoption pro des EE : ansible-navigator pour exécuter, ansible-builder pour construire, scan/signature/CI durcie pour publier. Incontournable sur AAP 2.6 et régulièrement à l'examen RHCE EX294.

Aller droit au but

🚀 Installation Podman + navigator Podman + ansible-navigator + ansible-builder sur AlmaLinux 10

📚 Modes interactifs (TUI vs stdout) ansible-navigator run, sous-commandes, fichier ansible-navigator.yml

🎯 Construire un EE custom execution-environment.yml v3, ansible-builder, multi-stage, pinning

🔥 Pipeline CI/CD durci Build, Trivy scan, cosign keyless, push registre privé

Ce que vous allez apprendre

Comprendre ce qu'est un EE OCI et pourquoi il remplace progressivement le venv local.
Installer Podman + ansible-navigator + ansible-builder sur AlmaLinux 10.
Exécuter un playbook dans un EE avec ansible-navigator run (TUI vs stdout).
Inspecter les collections, ansible-core, Python deps d'un EE existant.
Construire un EE custom avec execution-environment.yml v3.
Sécuriser la chaîne : pinning, scan Trivy, signature cosign.

Prérequis

Avant cette section, vous devez avoir validé :

Découvrir Ansible : architecture, push SSH.
Premiers pas : premier playbook.
Collections Ansible : FQCN, ansible-galaxy collection install.
Bases Podman (pull, run, images, inspect).

Mon retour d'expérience, pour ceux qui veulent comprendre

Si l'une des cartes en haut de page vous a déjà orienté, vous êtes parti sur le bon pied. La suite de cette page s'adresse à ceux qui veulent comprendre la philosophie de cette section : pourquoi je pousse à basculer vers les EE même hors AAP, pourquoi ansible-playbook reste valable en dev, et pourquoi je refuse les images sans signature en prod.

J'ai accompagné plusieurs équipes dans leur passage venv local → EE OCI entre 2022 et 2025. Le verdict : les équipes qui résistent au changement « parce que ansible-playbook suffit » se retrouvent en panique le jour où elles découvrent que leur AAP refuse leur playbook. L'EE n'est pas un sur-équipement, c'est l'unité de déploiement standard d'Ansible 2026, comme Docker l'est pour les apps. Cette section compile ce que j'ai appris à ne jamais relâcher dans un EE qui part en prod.

Pourquoi les EE plutôt qu'un venv local

Trois constats motivent le passage aux EE :

Drift de versions : un dev avec ansible-core 2.17.5 + community.general 9.0.0, un autre avec 2.18.1 + 10.5.0, le CI avec encore une autre combinaison. Modules dépréciés, comportements subtilement différents → bugs en prod.
Onboarding fragile : nouveau collègue installe Ansible avec sa version distro, ne match pas ce qui tourne sur AWX → playbook KO chez lui.
AAP impose les EE : Automation Controller 2.5/2.6 exécute uniquement dans des EE. Pas d'autre choix en prod entreprise.

Un EE résout ces 3 points : image OCI immuable versionnée, pinned strictement, distribuée par registre OCI (Quay, Harbor, GHCR). Le runtime est figé bit-pour-bit.

Le bon outil pour la bonne tâche

Outil	Rôle	Quand l'utiliser
`ansible-playbook`	Exécuteur classique (venv local)	Itération rapide en dev, scripts ponctuels
`ansible-navigator`	Exécuteur dans un EE	Production, CI/CD, formation, AAP
`ansible-builder`	Constructeur d'EE	Créer / mettre à jour son EE custom
`podman`	Runtime conteneur	Sous-jacent aux 3 ci-dessus

Vous resterez sur ansible-playbook côté dev pour itérer rapidement sur un nouveau playbook (~0.5 s vs ~3 s avec navigator). Dès que vous shippez (CI, prod, formation), vous bascule sur ansible-navigator + EE.

Les images EE communautaires en 2026

Image	Taille	Usage
`quay.io/ansible/creator-ee`	~1.2 GB	Formation, dev. Riche : ansible-lint, navigator deps, nombreuses collections.
`quay.io/ansible/awx-ee`	~900 MB	AWX upstream self-hosted.
`quay.io/ansible/community-ee-minimal`	~400 MB	Base minimale pour custom EE.
`registry.redhat.io/.../ee-supported-rhel9`	~1 GB	Production AAP avec collections certifiées Red Hat (Subscription).

Décision pratique : formation et lab → creator-ee. Production sans contrat Red Hat → custom EE basé sur community-ee-minimal. Production AAP entreprise → ee-supported-rhel9 ou custom basé dessus.

Ce que je défends pour les EE

Cinq positions tranchées que cette section assume :

version: 3 dans execution-environment.yml. Le format v1 ignore silencieusement les sections de deps. Bug le plus fréquent en formation. Si vous écrivez un EE en 2026, c'est v3, point.
Pinning strict de bout en bout. ansible-core en version exacte (pas >=), collections par tag (pas branche), Python deps en requirements.txt figé, packages système par version dans bindep.txt. Le coût d'un drift en prod est mille fois supérieur au confort d'écrire :latest.
Smoke test post-build mandatory. podman run --rm $TAG ansible --version après chaque build. Un EE peut builder « OK » et ne contenir aucun ansible-core (cas du version: 3 manquant). Vérifier en 2 secondes vaut mieux que découvrir le bug en prod.
Trivy scan + cosign sign en CI. Pas optionnel. Une CVE critique non patchée dans un EE = root sur tout votre parc. La chaîne build → scan → sign → push est l'équivalent OCI de ansible-test sanity : non négociable.
ansible-playbook reste valable en dev local. Itération rapide (~0.5 s vs 3 s navigator). Bascule sur navigator dès qu'on shippe (CI, prod, formation). Pas de dogme, chaque outil sur son créneau.

Ce que je vous interdis

Cinq erreurs typiques sur les EE, chacune coûteuse à diagnostiquer :

:latest sur l'image de base ou les collections. Reproductibilité cassée, drift garanti à chaque build. Pinning strict ou vous n'avez pas un EE, vous avez une image flottante qui marche aujourd'hui et plante demain.
version: 3 oublié dans execution-environment.yml. ansible-builder lit en mode v1, ignore les sections de deps. Le build « réussit » mais l'EE est vide. Smoke test post-build le détecte immédiatement.
Volumes Podman sans :Z sur SELinux activé. Permission denied qui ressemble à un bug Ansible alors que c'est SELinux qui bloque. :Z sur tout bind mount sur RHEL/AlmaLinux.
Python interpreter mismatch. L'EE embarque Python 3.11, la cible AlmaLinux 8 a 3.6, modules avec deps natives plantent. ansible_python_interpreter dans l'inventaire pour pointer vers le bon Python sur la cible.
Push d'EE non signé sur registre public. Sans cosign, pas de garantie d'intégrité. Un attaquant qui prend le contrôle du registre peut substituer votre image. cosign sign --keyless en CI = SBOM + signature, gratuit et vérifié.

Le parcours en 4 phases

Le parcours est séquentiel. Chaque phase suppose acquise la précédente.

Phase 1, Comprendre et exécuter

Le minimum vital : qu'est-ce qu'un EE, comment lancer un playbook avec ansible-navigator.

Présentation des EE Définition exacte 2026, contenu type, format OCI, AAP context.

Installation et configuration Podman + ansible-navigator + ansible-builder sur AlmaLinux 10.

Modes interactifs (TUI vs stdout) ansible-navigator run, sous-commandes, fichier ansible-navigator.yml.

Phase 2, Inspecter un EE

Avant de builder son propre EE, savoir quels EE existent et ce qu'ils contiennent.

Inspecter un EE (images, doc, collections) ansible-navigator images, doc, collections, TUI riche pour explorer.

Phase 3, Construire son EE custom

Le cœur du sujet : execution-environment.yml v3, ansible-builder, pinning rigoureux.

Construire un EE avec ansible-builder Schéma v3, multi-stage build, requirements, bindep, additional_build_steps.

Phase 4, Exécuter en CI/CD et signer

Build automatisé, scan, signature, push. Pour la production.

Exécution en CI/CD GitHub Actions et GitLab CI : build, Trivy, push, cosign keyless.

Vue d'ensemble du flux complet

┌────────────────────┐
│  execution-       │
│  environment.yml  │
│  + requirements   │  ──▶  ansible-builder build  ──▶  Image OCI custom
│  + bindep.txt     │
└────────────────────┘
           │
           ▼
   Trivy scan + cosign sign  ──▶  Push registre privé (Quay, GHCR)
           │
           ▼
   ansible-navigator run / AAP Controller / CI  ──▶  Exécution sur cibles

Bénéfice clé : à n'importe quel moment, n'importe qui peut rejouer le même runtime en pull-ant l'image taggée :1.4.2. Aucun "pip install" surprise, aucune collection Galaxy qui change sous les pieds.

À retenir

Un EE est une image OCI qui empaquette ansible-core + collections + deps Python + system.
ansible-navigator lance un playbook dans un EE (TUI ou stdout) ; ansible-builder construit l'EE.
version: 3 obligatoire dans execution-environment.yml en 2026.
Pinning strict sur toutes les couches (ansible-core, collections, Python, system).
creator-ee pour la formation/dev, community-ee-minimal comme base custom, ee-supported-rhel9 pour AAP enterprise.
CI 2026 : build → Trivy → push → cosign keyless. Actions GitHub pinnées par SHA, permissions: {}, persist-credentials: false.

Prochaines étapes

Commencer : Présentation des EE Définition complète, contenu type, comparaison venv vs EE.

Installation rapide Podman + ansible-navigator + ansible-builder sur AlmaLinux 10.

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

Pipeline CI/CD GitHub Actions + GitLab CI : build, scan, sign, push.