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é

Pressé ? Voici la bascule EE en 30 secondes

1. pipx install ansible-navigator ansible-builder + Podman opérationnel.
2. Tester l’image communautaire : ansible-navigator run playbook.yml --eei creator-ee.
3. Construire votre EE : execution-environment.yml v3 + requirements.yml + bindep.txt.
4. Pinning strict sur ansible-core, collections, Python deps — pas de :latest.
5. CI : build → Trivy → cosign sign → push sur registre privé (Quay, Harbor, GHCR).

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

Un EE sans pinning n'est pas un EE

J’ai vu des équipes shipper des EE avec ansible-core: latest et community.general: latest. Le jour où une release casse une signature de fonction, la prod plante sans changement côté votre repo. Le pinning bit-pour-bit est la moitié de la valeur d’un EE — sans lui, vous payez la complexité OCI sans gagner la reproductibilité. Cette section vous interdit explicitement les images flottantes.

---

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

Glissez pour voir

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

Glissez pour voir

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.

×

📖 Voir la documentation →