AWX en production légère sans usine à gaz

AWX est souvent abordé comme une plateforme à déployer avant d’être abordé comme un service à exploiter. C’est pourtant l’ordre inverse qui évite le plus d’erreurs. Dans une petite ou moyenne infrastructure, la question utile n’est pas seulement de savoir comment installer AWX, mais de déterminer ce que l’on accepte de lui confier, comment les inventaires sont maintenus, qui peut lancer les jobs, comment les secrets sont protégés, et comment revenir en service après un incident.

Une installation légère peut être parfaitement pertinente si le périmètre est clair. AWX n’a pas besoin de devenir immédiatement une plateforme complexe avec haute disponibilité, intégration complète à tous les outils internes et gouvernance avancée. Pour beaucoup d’équipes, il peut commencer comme un point central d’exécution Ansible, avec quelques projets Git, des inventaires contrôlés, des credentials séparés, et des templates de jobs réservés aux opérations récurrentes.

Le piège consiste à confondre installation réussie et service prêt à produire. Une interface accessible, un premier playbook qui fonctionne et un inventaire importé ne suffisent pas. AWX ajoute une couche d’orchestration au-dessus d’Ansible. Cette couche devient critique dès qu’elle lance des changements sur plusieurs serveurs, redémarre des services, applique des configurations de sécurité ou manipule des comptes. Même dans un format léger, elle doit être pensée comme un outil d’exploitation.

Définir le périmètre avant l’installation

Le premier choix est fonctionnel. AWX ne doit pas tout faire dès le premier jour. Il vaut mieux commencer par quelques usages maîtrisés : vérification de conformité, déploiement de paquets, exécution de contrôles Linux, tâches Active Directory indirectes, opérations de maintenance ou automatisation d’un périmètre cloud. Ces usages doivent avoir un niveau de risque compatible avec la maturité de la plateforme.

Un job qui lit l’état de serveurs n’a pas le même impact qu’un job qui modifie une configuration réseau ou redémarre un service critique. Le modèle d’accès doit suivre cette différence. Les templates de jobs de lecture peuvent être plus largement accessibles. Les templates de changement doivent rester limités, documentés et idéalement validés par une procédure interne.

La séparation des environnements est également importante. Mélanger développement, recette et production dans les mêmes inventaires sans convention claire crée rapidement des accidents. AWX permet d’organiser les inventaires, les groupes, les credentials et les templates, mais il ne compense pas une mauvaise discipline de nommage. Une installation légère doit donc être simple, mais pas improvisée.

Périmètre initial AWX
Jobs de lecture et de contrôle
Maintenance système standardisée
Déploiements Ansible déjà testés hors AWX
Inventaires limités et identifiables

Hors périmètre au démarrage
Changements réseau sensibles
Opérations destructives sans validation
Secrets partagés entre équipes
Jobs non versionnés dans Git

Ne pas négliger les composants persistants

AWX s’appuie sur plusieurs composants. Même si l’interface est ce que l’on voit en premier, le service dépend aussi de la base de données, des volumes persistants, des projets synchronisés, des credentials et de la configuration de l’operator lorsqu’il est utilisé sur Kubernetes. Une installation légère ne doit pas ignorer ces éléments sous prétexte que le déploiement est petit.

La base de données est particulièrement importante. Elle contient l’état applicatif, les configurations AWX, les templates, les liens avec les credentials, les historiques et les objets de la plateforme. Sans sauvegarde exploitable, une panne peut obliger à reconstruire AWX à la main. Les playbooks restent dans Git, mais l’organisation AWX disparaît. Pour une plateforme censée standardiser les opérations, cette situation n’est pas acceptable.

Les projets doivent rester dans Git. AWX ne doit pas devenir l’endroit où l’on écrit directement une logique d’automatisation non versionnée. Le dépôt Git reste la source de vérité. AWX exécute, trace, contrôle les accès et centralise les lancements. Cette séparation est simple, mais elle évite une dérive fréquente : traiter AWX comme un mélange d’interface, de dépôt et de serveur d’exécution informel.

Les credentials doivent être séparés par usage. Un compte unique avec beaucoup de droits donne une illusion de simplicité, mais il rend l’audit difficile. Les accès de lecture, de maintenance et de changement doivent être distingués lorsque c’est possible. Un job qui collecte de l’information n’a pas besoin des mêmes droits qu’un job qui modifie une configuration système.

Superviser AWX comme un outil d’exploitation

Une plateforme AWX légère doit être surveillée. Il ne s’agit pas seulement de vérifier que la page web répond. Il faut surveiller l’état des pods ou services, la base de données, les files de jobs, l’espace disque, les erreurs de synchronisation Git, les échecs répétés de credentials et les durées anormales d’exécution.

Un job en échec peut signaler une erreur de playbook, mais aussi un problème plus large : DNS cassé, compte expiré, changement de clé SSH, inventaire obsolète ou indisponibilité réseau. Si AWX devient le point central d’exécution, ses erreurs deviennent des signaux d’exploitation. Les ignorer revient à perdre une partie de la valeur de la plateforme.

La rétention des logs doit être pensée. Garder trop peu d’historique limite les diagnostics. Garder trop d’historique sans nettoyage augmente le volume de données et peut peser sur la base. Une petite plateforme doit choisir une durée cohérente avec ses besoins d’audit et de dépannage, plutôt que laisser la valeur par défaut décider.

Contrôles minimaux
Interface accessible
Base de données disponible
Synchronisation Git fonctionnelle
Jobs non bloqués en file
Espace disque suffisant
Taux d'échec inhabituel détecté
Credentials critiques non expirés

Garder une stratégie de mise à jour simple

AWX évolue régulièrement. Une installation légère doit donc avoir une méthode de mise à jour, même minimale. L’erreur classique consiste à installer AWX, l’utiliser pendant des mois, puis découvrir que la montée de version est devenue risquée parce que personne ne sait exactement comment la plateforme a été construite.

La configuration de déploiement doit être conservée dans Git. Les manifests, les valeurs de configuration, les paramètres de stockage, les ingress, les certificats et les dépendances doivent être reproductibles. Une mise à jour doit pouvoir être testée dans un environnement séparé ou au moins validée sur une copie représentative. Sans cela, chaque upgrade devient une opération manuelle incertaine.

Le rollback doit être réaliste. Revenir à une version précédente ne signifie pas seulement redéployer une image. Il faut aussi considérer l’état de la base de données, les migrations déjà appliquées et les sauvegardes disponibles. Une sauvegarde avant mise à jour n’est pas une formalité. C’est le point de retour en cas d’échec.

Conclusion

AWX en production légère n’est pas un compromis faible si le cadre est clair. Une petite plateforme bien exploitée vaut mieux qu’une grande installation mal gouvernée. Le point essentiel est de traiter AWX comme un service d’exploitation, avec des limites définies, des inventaires propres, des playbooks versionnés, des credentials séparés, une sauvegarde testable et une supervision minimale.

La bonne question n’est donc pas de savoir si AWX doit être installé de manière lourde ou légère. Elle est plus concrète : si AWX tombe en panne demain, si un credential expire, si un job critique échoue ou si une mise à jour casse la plateforme, l’équipe sait-elle quoi regarder, quoi restaurer et quoi ne pas relancer sans validation ? Si la réponse est oui, l’installation légère peut être un vrai outil de production.