AWX : piloter Ansible depuis une interface web

Si vous avez suivi le tutoriel « Ansible : installation et prise en main », vous savez maintenant écrire et exécuter des playbooks en ligne de commande. Très bien pour un usage personnel ou une petite équipe technique — plus limité dès qu’il faut partager l’automatisation avec des collègues moins à l’aise en CLI, garder un historique centralisé des exécutions, ou restreindre qui a le droit de lancer quoi. C’est exactement ce qu’apporte AWX.

Qu’est-ce qu’AWX ?

AWX est le projet open source qui sert de base amont (upstream) au produit commercial Red Hat Ansible Automation Controller (anciennement « Ansible Tower »). Il ajoute une couche web complète au-dessus du moteur Ansible :

• Une interface web pour lancer des playbooks sans taper de commande
• Une API REST complète pour intégrer l’automatisation dans d’autres outils
• La gestion centralisée des credentials (SSH, cloud, vault) chiffrés en base, jamais exposés en clair aux utilisateurs
• Le RBAC (contrôle d’accès basé sur les rôles) : qui peut voir, modifier ou exécuter quoi, par organisation et par équipe
• La planification de jobs récurrents et les notifications (email, Slack…) en cas d’échec
• Un historique complet et consultable de chaque exécution, avec les logs détaillés de chaque tâche
• Des inventaires dynamiques synchronisés automatiquement depuis vos sources (cloud, VMware, fichiers)

En résumé : Ansible reste le moteur d’exécution ; AWX est la tour de contrôle qui l’entoure pour un usage en équipe.

Prérequis

Depuis plusieurs versions, AWX se déploie exclusivement via l’awx-operator sur un cluster Kubernetes — l’ancienne méthode par Docker Compose est abandonnée. Pour tester ou pour un usage en petite structure, un cluster Minikube local suffit très bien.

• kubectl installé et configuré
• kustomize (intégré à kubectl depuis la version 1.14, via kubectl apply -k)
• Minikube pour un déploiement de test, ou un cluster Kubernetes existant avec une StorageClass supportant le provisionnement dynamique en production
• Au minimum 4 CPU et 6 Go de RAM alloués au cluster de test

Étape 1 — Préparer un cluster de test avec Minikube

minikube start --cpus=4 --memory=6g --addons=ingress
kubectl cluster-info

Étape 2 — Déployer l’awx-operator

Créez un dossier de déploiement avec un fichier kustomization.yaml. Vérifiez au préalable, sur la page des releases GitHub d’ansible/awx-operator, la dernière version stable disponible plutôt que de recopier un numéro figé qui sera vite dépassé :

mkdir awx-deploy && cd awx-deploy
cat > kustomization.yaml <<EOF
resources:
  - github.com/ansible/awx-operator/config/default?ref=VERSION_A_VERIFIER
images:
  - name: quay.io/ansible/awx-operator
    newTag: VERSION_A_VERIFIER
namespace: awx
EOF

kubectl apply -k .
kubectl get pods -n awx --watch

Patientez jusqu’à ce que le pod awx-operator-controller-manager passe en statut Running avant de continuer.

Étape 3 — Déployer l’instance AWX elle-même

L’opérateur étant en place, il ne reste qu’à lui déclarer une ressource personnalisée AWX pour qu’il provisionne automatiquement la base de données, le service web et les pods nécessaires :

cat > awx-demo.yml <<EOF
---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx-demo
  namespace: awx
spec:
  service_type: nodeport
EOF

kubectl apply -f awx-demo.yml
kubectl get pods -n awx --watch

Le premier déploiement peut prendre plusieurs minutes (migration de base de données incluse) — un comportement normal, pas un blocage à corriger.

Étape 4 — Récupérer le mot de passe administrateur

kubectl get secret awx-demo-admin-password -n awx \
  -o jsonpath="{.data.password}" | base64 --decode ; echo

L’identifiant par défaut est admin.

Étape 5 — Accéder à l’interface web

# Avec Minikube
minikube service awx-demo-service --url -n awx

# Ou via un port-forward classique
kubectl port-forward service/awx-demo-service -n awx 8080:80

Ouvrez l’URL obtenue (ou http://localhost:8080 avec le port-forward) et connectez-vous avec admin et le mot de passe récupéré à l’étape précédente.

Étape 6 — Premiers pas dans l’interface

1. Credentials : créez un credential de type « Machine » avec votre clé SSH privée — c’est ce qui remplace la clé locale que vous utilisiez en ligne de commande, désormais stockée chiffrée côté serveur.
2. Projects : déclarez un projet pointant vers votre dépôt Git contenant les playbooks (le même que celui utilisé dans le tutoriel Ansible précédent). AWX synchronise automatiquement la dernière version à chaque exécution.
3. Inventories : recréez votre inventaire, soit manuellement (import du fichier inventory.ini), soit via une source dynamique si vos machines viennent d’un cloud ou d’un hyperviseur déjà supporté.
4. Job Templates : associez un playbook du projet, un inventaire et un credential dans un modèle de job réutilisable — c’est l’équivalent web de votre commande ansible-playbook.
5. Lancez le job depuis l’interface et suivez l’exécution en direct, tâche par tâche, avec le même niveau de détail que la sortie CLI d’Ansible.

RBAC : organiser les accès en équipe

AWX structure les permissions autour de trois notions :

• Organizations : le regroupement de plus haut niveau (une organisation par client, par exemple, dans un contexte de prestation).
• Teams : des groupes d’utilisateurs au sein d’une organisation.
• Rôles attribués à un niveau précis (projet, inventaire, job template…) : Admin, Execute (lancer un job sans pouvoir le modifier), Read seulement, etc.

Bonne pratique : donnez le rôle Execute à la majorité des utilisateurs sur les job templates de production — ils peuvent lancer les automatisations validées, sans pouvoir modifier les playbooks ni les credentials sous-jacents.

Bonnes pratiques et limites à connaître

• Sauvegardez la base de données du cluster AWX régulièrement — elle contient l’historique des jobs, les credentials chiffrés et toute la configuration ; sa perte revient à repartir de zéro.
• Mettez à jour l’opérateur en changeant la référence de version dans kustomization.yaml puis en réappliquant — ne modifiez jamais les ressources Kubernetes générées à la main.
• AWX ajoute une couche d’infrastructure (Kubernetes) à maintenir en plus d’Ansible lui-même — pour une équipe d’une ou deux personnes gérant quelques serveurs, la ligne de commande reste souvent plus simple ; AWX devient pertinent dès que plusieurs personnes doivent partager l’automatisation en toute sécurité.
• Si le support commercial et les garanties de version vous importent, la version payante Ansible Automation Platform de Red Hat s’appuie sur les mêmes concepts qu’AWX, avec du support officiel en plus.