Un Execution Environment (EE) est une image conteneur OCI qui empaquette tout ce dont Ansible a besoin pour s’exécuter : ansible-core, ansible-runner, des collections Galaxy, des dépendances Python et des packages système (git, sshpass, openssh-clients). Cette page définit précisément le concept, son contenu, et le compare avec les approches précédentes (venv local, image Docker générique).
À la fin, vous saurez exactement ce qui vit dans un EE, ce qui n’y vit pas, et pourquoi Red Hat l’a imposé sur Ansible Automation Platform 2.x dès 2021.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Définition exacte d’un EE (vs Docker image générique).
- Contenu type : ansible-core, ansible-runner, collections, deps Python, deps système.
- Format OCI : compatible Podman, Docker, Skopeo, Buildah.
- Différence avec un venv local : reproductibilité, isolation, portabilité.
- Place dans AAP : Automation Controller, AWX, Tower.
Prérequis
Section intitulée « Prérequis »- Bases Podman (
podman --version,podman run,podman images). - Notion de collection Ansible et FQCN.
Définition exacte (2026)
Section intitulée « Définition exacte (2026) »Un Execution Environment est une image conteneur au format OCI (Open Container Initiative). Le format OCI normalise la structure d’une image entre runtime — Podman, Docker, containerd, CRI-O sont tous compatibles. Une image OCI publiée sur Quay, Docker Hub, GitHub Container Registry ou Harbor est lisible par tous ces outils sans conversion.
L’EE est introduit avec Ansible Automation Platform 2.0 (octobre 2021) pour résoudre un problème opérationnel : sur Tower 1.x, le serveur Ansible exécutait directement les playbooks dans son propre venv, source de drift et de conflits. AAP 2.x déplace l’exécution dans un conteneur isolé, avec un runtime figé.
Sur AAP 2.6 (sortie 2026), l’EE est le seul mode d’exécution disponible — pas de fallback “venv local”. Maîtriser les EE est donc devenu non négociable pour quiconque touche à AAP en production.
Contenu type d’un EE
Section intitulée « Contenu type d’un EE »Un EE typique embarque 6 couches logicielles :
| Couche | Rôle | Exemple 2026 |
|---|---|---|
| Image de base OCI | OS minimal | UBI 9 (Universal Base Image Red Hat) |
| Python interpreter | Runtime Python | Python 3.11 ou 3.12 |
ansible-core | Le moteur Ansible | 2.18.x |
ansible-runner | API programmatique pour lancer Ansible | 2.4.x |
| Collections Galaxy | ansible.posix, community.general, etc. | Pinnées en versions exactes |
| Deps Python | Modules requis par certaines collections | kubernetes, pywinrm, boto3 |
| Deps système | Outils CLI nécessaires | git, openssh-clients, sshpass |
Tout est figé au moment du build. Une fois l’image taguée (my-ee:1.4.2), rien ne change — c’est le contraire d’un venv qui peut subir un pip install --upgrade à tout moment.
Format OCI — ce que ça implique
Section intitulée « Format OCI — ce que ça implique »Une image OCI est une série de couches (layers) + un manifest + une config. Conséquences concrètes :
- Reproductible : un manifest référence les layers par digest SHA-256.
pullla même image deux fois produit le même contenu, bit-pour-bit. - Distribuable : push sur n’importe quel registre OCI (Quay, GHCR, Harbor, Artifactory, ECR, GCR).
- Inspectable :
podman inspect,skopeo inspect,crane manifestlistent les layers, l’image base, les commandes lancées. - Signable :
cosign signajoute une attestation Sigstore liée au digest.cosign verifyla valide avant exécution.
C’est le standard de l’industrie depuis 2017 — adopté par Kubernetes, Docker, OpenShift, AKS, EKS. Les EE héritent de toute cette infrastructure mature.
Différence vs venv Python local
Section intitulée « Différence vs venv Python local »| Critère | Venv local | EE OCI |
|---|---|---|
| Création | python -m venv ; pip install ansible | podman pull quay.io/... |
| Reproductibilité | Selon l’état du PyPI au moment du pip install | Bit-pour-bit identique partout |
| Portabilité | Recréer le venv sur chaque poste | Pull la même image |
| Versioning | pip freeze > requirements.txt (fragile) | Tag image semver |
| Onboarding | « Suivez ces 5 commandes » | « podman pull » |
| Démarrage | Immédiat | +1-3 s (lancement conteneur) |
| Dev iteratif | Excellent (recharge rapide) | Moins fluide |
| Prod / CI | Drift garanti à terme | Stable |
Décision pratique : venv local pour itérer en dev sur un nouveau playbook. EE pour shipper.
Différence vs Docker image générique
Section intitulée « Différence vs Docker image générique »Un EE n’est pas une simple image Docker contenant Ansible. Il a des conventions précises :
- Layout
/runner/attendu paransible-runner(inventory, project, env). /etc/ansible/configurable viaadditional_build_steps.- Métadonnées d’image spécifiques (label
ansible.com/runneretc.). ENTRYPOINToptimisé pouransible-runner(pas un shell générique).
Un Dockerfile artisanal qui installe ansible-core marchera techniquement, mais ne sera pas optimal avec ansible-navigator ni AAP. Toujours partir des base images officielles (creator-ee, community-ee-minimal, ee-supported-rhel9).
Place dans Ansible Automation Platform
Section intitulée « Place dans Ansible Automation Platform »Sur AAP, on retrouve les EE dans Automation Controller :
- Onglet “Execution Environments” : registre des EE disponibles.
- Project : dépôt Git des playbooks.
- Job Template : playbook + inventaire + EE associé. Le job tourne dans cet EE.
- Credentials : crédentials Vault, Cloud, Git — montés dans l’EE au runtime.
Pareil sur AWX upstream (l’open-source en amont d’AAP) : même UI, mêmes concepts, image AWX-EE par défaut (quay.io/ansible/awx-ee).
Cas concret — pourquoi c’est mieux qu’un venv
Section intitulée « Cas concret — pourquoi c’est mieux qu’un venv »Scénario : équipe DevOps de 5 personnes, projet Ansible avec 30 playbooks, déploiement sur 200 serveurs.
Avec venv local :
- Anna installe Ansible 2.17.5 via
dnf(paquet distro AlmaLinux). - Bruno installe 2.18.1 via
pipx. - Le runner GitLab CI utilise une image avec 2.16.x (vieille).
- Trois mois plus tard, un module
ansible.builtin.dnfse comporte légèrement différemment entre 2.16 et 2.18 → un playbook qui marche en CI plante chez Anna. - Debug : 4 heures pour aligner les versions, retests, redéploiement.
Avec EE :
- Tous (dev + CI + AAP) tirent
acme/my-ee:1.4.2. - Identique partout. Si quelque chose change, c’est par un commit explicite sur
execution-environment.yml. - Bump de version : un seul tag à pousser, tout le monde repulled la nouvelle version.
C’est exactement le bénéfice apporté par Docker sur les apps web depuis 2014 — appliqué à Ansible.
Lab pratique
Section intitulée « Lab pratique »Le lab ee/hello du repo ansible-training fait passer du concept à la pratique : install Podman + ansible-navigator, pull creator-ee, lance un premier playbook en TUI puis en stdout. 6 tests pytest valident la structure du lab.
Suivre : labs/ee/hello/README.md.
À retenir
Section intitulée « À retenir »- Un EE = image OCI qui empaquette ansible-core + ansible-runner + collections + deps Python + deps système.
- Format standard : compatible Podman, Docker, AAP, AWX, CI/CD.
- Reproductibilité : tag immuable, identique partout, pas de drift.
- Imposé sur AAP 2.6 : seul mode d’exécution disponible côté Controller.
- Dev : venv local reste plus rapide. Ship : EE obligatoire.
- 6 couches : OS base + Python + ansible-core + ansible-runner + collections + deps.