AWX et Ansible Tower

Gérer Ansible depuis la ligne de commande fonctionne pour un seul ingénieur. Dès qu'une équipe s'implique, les questions de traçabilité, d'accès partagé, d'audit et de scheduling surgissent. AWX répond à ces besoins : c'est l'interface de gestion web d'Ansible, open-source et auto-hébergeable.

AWX, Tower, et Ansible Automation Platform

• AWX : upstream open-source, développé par Red Hat, disponible sur GitHub. Gratuit, sans support commercial. Mis à jour fréquemment.
• Ansible Tower : version commerciale et supportée d'AWX. Remplacée par AAP depuis 2021.
• Ansible Automation Platform (AAP) : offre Red Hat complète incluant Execution Environments, Private Automation Hub, et Event-Driven Ansible. Nécessite un abonnement Red Hat.

Pour une infrastructure auto-hébergée sans budget Red Hat, AWX est le choix naturel. La plupart des concepts s'appliquent identiquement à Tower et AAP.

Ce qu'AWX apporte concrètement

• Interface web : lancer des playbooks, consulter les logs, sans accès SSH au nœud de contrôle
• RBAC : contrôle d'accès granulaire par organisation, équipe, utilisateur et ressource
• Credentials centralisés : les clés SSH et mots de passe ne circulent plus entre les ingénieurs
• Scheduling : exécution planifiée de playbooks (cron-like)
• Logs centralisés : historique complet des runs avec sortie détaillée
• API REST : intégration avec les pipelines CI/CD, les outils ITSM, les webhooks
• Notifications : email, Slack, webhook sur succès ou échec

Architecture interne

AWX est une application Django/Python qui tourne sur Kubernetes. Les composants principaux :

• awx-web : API REST + interface web (Django)
• awx-task : exécuteur de jobs Ansible
• PostgreSQL : base de données (jobs, inventaires, credentials, users)
• Redis : file de messages entre les composants
• Receptor : mesh réseau pour les exécutions distribuées (AWX 19+)

Quand passer d'Ansible CLI à AWX

Passer à AWX n'est pas toujours justifié. L'overhead de maintenance d'un cluster Kubernetes pour AWX est réel. Les critères qui justifient le passage :

• Équipe de plus de 2 ingénieurs qui doivent tous pouvoir lancer des playbooks
• Nécessité d'audit trail (qui a lancé quoi, quand, avec quel résultat)
• Playbooks à exécuter régulièrement selon un planning
• Intégration requise avec un pipeline CI/CD ou un outil ITSM
• Gestion de credentials partagés sans les distribuer en clair

Pour un ingénieur seul avec 20 serveurs, la CLI Ansible et Git suffisent largement.