ℹ️ À savoir · En bref
Lancer ansible-playbook depuis son poste ne passe pas à l'échelle : pas de traçabilité, secrets dispersés, droits flous. AWX (projet open source) et Ansible Automation Platform (offre Red Hat, dont le cœur est l'*automation controller*, ex-Tower) centralisent l'exécution : interface web, API, droits, journal de chaque exécution.
Les playbooks restent dans Git ; la plateforme les exécute dans des environnements d'exécution (conteneurs) reproductibles.
Objectifs de la fiche
- Comprendre les objets d'AWX / AAP et comment ils s'assemblent.
- Construire un environnement d'exécution avec ses collections.
- Exposer un playbook en libre-service (survey) avec les bons droits.
- Brancher Ansible dans une chaîne CI/CD.
AWX ou Ansible Automation Platform ?
| AWX | Ansible Automation Platform | |
|---|---|---|
| Nature | Projet communautaire, amont (upstream) | Produit Red Hat supporté |
| Installation | AWX Operator sur Kubernetes | Installeur conteneurisé, RPM ou OpenShift |
| Cycle de vie | Versions fréquentes, pas de support | Versions stabilisées, support, certifications |
| Composants en plus | — | Private Automation Hub, Event-Driven Ansible, automation mesh, collections certifiées |
| Pour qui | Lab, PME, apprentissage | Production en entreprise |
Les objets et leur assemblage
| Objet | Rôle |
|---|---|
| Organisation / équipes | Cloisonnement et droits : qui voit, modifie ou lance quoi |
| Projet | Pointe vers un dépôt Git (branche ou tag) ; synchronisé avant exécution |
| Inventaire | Statique, issu d'un fichier du projet, ou dynamique (Azure, vCenter, AD…) rafraîchi automatiquement |
| Identifiants (credentials) | Comptes machine, Vault, cloud, Git : chiffrés en base, injectés au lancement, jamais affichés |
| Environnement d'exécution (EE) | Image conteneur avec ansible-core, Python et les collections nécessaires |
| Modèle de tâche (job template) | Playbook + inventaire + identifiants + EE + options (limit, tags, verbosité, survey) |
| Workflow | Enchaînement de modèles avec branches succès / échec et étapes d'approbation |
| Planification / webhook | Lancement à heure fixe, ou à chaque push Git |
Environnements d’exécution
Fini le « ça marche sur mon poste » : on décrit l'image, ansible-builder la construit, et la même image sert en local (ansible-navigator) et dans AWX.
execution-environment.yml
# execution-environment.yml
version: 3
images:
base_image:
name: quay.io/ansible/awx-ee:latest # ou une image de base Red Hat
dependencies:
galaxy: requirements.yml # ansible.windows, microsoft.ad, contoso.citrix…
python: requirements.txt # pywinrm[kerberos], pypsrp…
system: bindep.txt # krb5-devel, gcc…
additional_build_steps:
append_final:
- COPY krb5.conf /etc/krb5.conf
commandes
ansible-builder build -t registry.contoso.com/ee-citrix:1.0 # construire l'image
podman push registry.contoso.com/ee-citrix:1.0 # la publier
ansible-navigator run site.yml --eei registry.contoso.com/ee-citrix:1.0 -i inventory
# exécuter en local dans le même EE
💡 Astuce
Pour Windows en Kerberos, l'EE doit contenir pywinrm[kerberos] (ou pypsrp) et la configuration Kerberos du domaine : c'est la cause n°1 des échecs « ça marchait en ligne de commande » (voir ANS-03).
Libre-service : surveys et droits
- Un survey affiche un petit formulaire au lancement (liste de choix, texte, nombre) et transmet les réponses comme
extra_vars. - Exemple : un modèle « Ajouter des VDA au catalogue » demande le catalogue et le nombre de machines, puis lance le playbook ou le Terraform correspondant.
- Les droits (RBAC) séparent qui modifie un modèle (admin) de qui peut seulement l'exécuter (support N1).
- Les identifiants sont utilisables sans être visibles : le support lance la tâche sans jamais connaître le mot de passe du compte de service.
Déclencher depuis l’extérieur
déclenchement
# CLI awx (paquet awxkit) — même logique pour l'API REST
export CONTROLLER_HOST=https://awx.contoso.com
export CONTROLLER_OAUTH_TOKEN=<jeton> # depuis le coffre du pipeline
awx job_templates launch "Construire image VDA" \
--extra_vars '{"vda_version": "2507"}' --monitor
# Ou en Ansible, avec la collection awx.awx (ou ansible.controller pour AAP)
- name: Lancer la construction d'image
awx.awx.job_launch:
job_template: "Construire image VDA"
extra_vars: { vda_version: "2507" }
wait: true
ℹ️ À savoir
La configuration d'AWX elle-même (projets, modèles, droits) peut être décrite en code avec la collection awx.awx / ansible.controller : on versionne la plateforme comme le reste.
Le pipeline CI/CD
pipeline (exemple GitHub Actions)
# .github/workflows/ansible.yml (même principe dans Azure DevOps ou GitLab)
name: ansible-ci
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install ansible-core ansible-lint
- run: ansible-galaxy install -r collections/requirements.yml
- run: ansible-lint --profile production
molecule:
needs: lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install ansible-core molecule molecule-plugins[docker]
- run: molecule test
Pièges classiques
| Symptôme | Cause | Parade |
|---|---|---|
| « couldn't resolve module » dans AWX | Collection absente de l'EE | collections/requirements.yml dans le projet ou EE personnalisé |
| Échec Kerberos uniquement dans AWX | krb5.conf / bibliothèques absents de l'EE | Les ajouter à l'EE, tester avec ansible-navigator |
| L'exécution utilise un vieux playbook | Projet non synchronisé | « Mettre à jour à l'exécution » ou webhook Git |
| Secret visible dans la sortie | Variable affichée par debug ou erreur | no_log: true, identifiants AWX plutôt que variables |
| Inventaire dynamique incomplet | Filtres ou droits du compte cloud | Vérifier la source et ses filtres, synchroniser manuellement |
🔷 En contexte Citrix
Workflow type : Terraform crée la VM maître → AWX lance le rôle d'image (ANS-03) → approbation → Terraform met à jour le catalogue MCS (TF-04). Une seule action pour un nouveau mois de patchs.
Libre-service pour le support : redémarrer un VDA bloqué, vider un profil, mettre un serveur en maintenance, sans droits d'administration directs.
À retenir
- AWX = amont communautaire ; AAP = produit Red Hat avec Hub, EDA et support.
- Modèle de tâche = projet + inventaire + identifiants + environnement d'exécution.
- ansible-builder construit l'EE, ansible-navigator l'utilise en local.
- Surveys + RBAC = libre-service sans exposer les secrets.
- CI : ansible-lint puis Molecule à chaque PR ; AWX exécute après fusion.
Auto-évaluation
Q1. Quelle différence entre AWX et Ansible Automation Platform ?
→ AWX est le projet communautaire non supporté ; AAP est le produit Red Hat supporté, qui ajoute Automation Hub privé, Event-Driven Ansible, automation mesh et collections certifiées.
Q2. Un playbook marche en local mais échoue dans AWX sur un module manquant. Pourquoi ?
→ La collection n'est pas dans l'environnement d'exécution : l'ajouter via requirements.yml du projet ou construire un EE avec ansible-builder.
Q3. Comment permettre au support de lancer une action sans connaître le mot de passe du compte de service ?
→ Créer un identifiant AWX attaché au modèle de tâche et donner au support le seul droit d'exécution sur ce modèle.
Q4. Quels contrôles placer dans la CI d'un dépôt de rôles ?
→ ansible-lint (profil production), puis Molecule (exécution, idempotence, vérifications) à chaque pull request.