Ansible en ligne de commande, c'est un vrai bonheur quand on est seul. Un inventaire, un playbook, ansible-playbook site.yml, et trente serveurs sont configurés pendant qu'on prend un café.

Le jour où l'équipe grandit, les questions changent. Qui a lancé ce playbook sur la production hier soir ? Avec quelle version du code ? Pourquoi est-ce que ça marche chez un collègue et pas chez moi ? Et pourquoi la clé SSH root de toute l'infra traîne-t-elle sur six ordinateurs portables ? C'est précisément là qu'Ansible Tower entre en jeu.

Tower, AAP, AWX : un peu de vocabulaire

• Ansible Tower : le nom historique de l'interface web et de l'API qu'on pose au-dessus d'Ansible.
• Ansible Automation Platform (AAP) : le produit Red Hat actuel, qui a intégré Tower (aujourd'hui appelé automation controller) avec d'autres briques.
• AWX : le projet open source d'où provient Tower. Gratuit, très complet, mais il se déploie sur Kubernetes via un opérateur, ce qui le rend assez lourd pour une petite équipe.

Les concepts sont les mêmes partout. J'emploie « Tower » dans la suite par simplicité.

Si vous débutez avec Ansible lui-même, ce court format résume le principe en une minute :

Les quatre briques de Tower

Tout repose sur quatre objets, et une fois qu'on les a compris, l'interface devient évidente :

• L'inventaire : sur quels serveurs ?
• Le projet : quel code ?
• Les credentials : avec quels accès ?
• Le job template : l'assemblage des trois, prêt à être lancé en un clic.

Au-dessus, une organisation regroupe équipes, utilisateurs et ressources. Par exemple une organisation pour l'équipe système et une autre pour l'équipe réseau, chacune avec ses propres inventaires et ses propres accès.

Étape 1 : l'inventaire

On y range les serveurs, classés en groupes (web, db, monitoring), avec leurs variables. On peut les saisir à la main, mais la vraie force, ce sont les sources d'inventaire dynamiques : AWS, Azure, GCP, VMware, OpenStack, Satellite… Tower synchronise régulièrement la liste, et un nouveau serveur créé dans le cloud apparaît tout seul, dans le bon groupe, grâce à ses étiquettes.

On peut aussi pointer un inventaire vers un fichier du dépôt Git, ce qui garde l'inventaire versionné avec le code.

Étape 2 : le projet

Un projet pointe vers un dépôt Git contenant vos playbooks, rôles et le fichier collections/requirements.yml. Avec l'option « mettre à jour avant lancement », Tower récupère la dernière version du code à chaque exécution. Le dépôt reste la seule source de vérité : personne ne lance un playbook modifié localement et jamais commité.

Étape 3 : les credentials

Clé SSH des serveurs, compte de service cloud, mot de passe Ansible Vault, token d'un coffre-fort externe (HashiCorp Vault, CyberArk) : tout est stocké chiffré dans Tower.

Et c'est là que ça devient vraiment intéressant : un utilisateur peut utiliser un credential sans jamais pouvoir le voir. Un développeur peut lancer un déploiement en production avec la clé SSH de production, sans jamais avoir cette clé sur son poste. Le jour où il quitte l'entreprise, il n'y a aucune clé à faire tourner.

Étape 4 : le job template

Le job template assemble tout : inventaire + projet + playbook + credentials, avec éventuellement des options (limite à un groupe, tags, niveau de verbosité, variables supplémentaires). On clique sur « Lancer », et c'est parti.

Suivre une exécution

La sortie s'affiche en direct, tâche par tâche, avec les mêmes couleurs que dans le terminal : vert pour ce qui était déjà conforme, jaune pour ce qui a changé, rouge pour les erreurs. Chaque job est conservé : qui l'a lancé, quand, avec quelle révision Git, quelles variables, et quel résultat sur chaque hôte.

C'est cet historique, à lui seul, qui change le plus le quotidien. Le jour où un serveur casse, on remonte les derniers jobs qui l'ont touché, et on sait.

Les surveys : Ansible pour ceux qui ne connaissent pas Ansible

Un survey est un petit formulaire affiché avant le lancement : liste déroulante de versions à déployer, nom d'utilisateur à créer, case à cocher « redémarrer après mise à jour ». Les réponses deviennent des variables du playbook.

Concrètement, ça permet de confier un déploiement à une personne du support ou de la recette, sans qu'elle ait à connaître la moindre commande Ansible, et sans lui donner plus de droits que nécessaire.

Les droits (RBAC)

Les permissions se donnent objet par objet, rôle par rôle :

• un développeur peut exécuter le job template de déploiement, mais pas le modifier ;
• un auditeur voit tout, mais ne peut rien lancer ;
• l'équipe réseau administre ses inventaires, sans toucher à ceux de l'équipe système.

L'authentification se branche sur l'annuaire de l'entreprise (LDAP, Active Directory, SAML), avec un mapping des groupes vers les équipes Tower.

Les planifications

N'importe quel job template peut être planifié : appliquer les mises à jour de sécurité tous les dimanches à 3 h, vérifier la conformité des serveurs chaque nuit, synchroniser l'inventaire cloud toutes les heures. Fini les crontabs dispersées sur une machine dont plus personne ne se souvient.

Niveau expert : les workflows

Un workflow enchaîne plusieurs job templates sous forme de graphe, avec des branches selon le résultat :

[Sauvegarde BDD] --succès--> [Déploiement] --succès--> [Tests de fumée]
                                  |                          |
                                échec                      échec
                                  v                          v
                            [Rollback] <---------------------+

On peut y insérer des synchronisations d'inventaire ou de projet, et même des étapes d'approbation : le workflow s'arrête et attend qu'un humain valide avant de toucher la production.

L'API et les callbacks

Tout ce qui se fait dans l'interface est disponible via l'API REST. Votre pipeline GitLab CI peut donc lancer un job template à la fin d'un build réussi :

curl -s -X POST \
  -H "Authorization: Bearer $TOWER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"extra_vars": {"version": "1.4.2"}}' \
  https://tower.mon-entreprise.fr/api/v2/job_templates/42/launch/

Il existe aussi un outil en ligne de commande (awx) et une collection Ansible (awx.awx ou ansible.controller) pour piloter Tower depuis un playbook.

Les provisioning callbacks renversent la logique : un serveur fraîchement créé appelle lui-même une URL de Tower (avec une clé), et Tower lance le job template de configuration sur ce seul serveur. Idéal pour l'autoscaling.

Les execution environments

Le fameux « ça marche sur ma machine » vient presque toujours d'une version différente d'Ansible, d'une collection, ou d'une bibliothèque Python. Les execution environments règlent le problème : ce sont des images de conteneur qui embarquent Ansible, les collections et leurs dépendances. Chaque job tourne dans une image connue et versionnée.

# execution-environment.yml (pour ansible-builder)
version: 3
images:
  base_image:
    name: quay.io/ansible/awx-ee:24.6.1
dependencies:
  galaxy:
    collections:
      - community.general
      - community.docker
  python:
    - hvac

ansible-builder build -t registry.mon-entreprise.fr/ee-infra:1.0

Les bonnes pratiques que je recommande

• Tout le code dans Git, et rien de modifié à la main sur les serveurs. Si une modification manuelle est nécessaire en urgence, elle est reportée dans le playbook juste après.
• Un inventaire par environnement (dev, recette, production), pour qu'une erreur de limit ne puisse pas toucher la production.
• Le moindre privilège pour les droits : exécuter n'est pas modifier.
• La configuration de Tower elle-même en code, avec la collection dédiée. Les job templates, inventaires et équipes deviennent reproductibles.

Et si Tower est trop lourd ?

C'est une vraie question. AWX demande un cluster Kubernetes, AAP une licence Red Hat. Pour une petite équipe ou une infra personnelle, c'est souvent disproportionné. Dans ce cas, je recommande Semaphore : les mêmes concepts (projets, clés, inventaires, modèles de tâches, historique), dans un seul conteneur Docker. Je lui ai consacré un article complet.

À retenir

Un inventaire pour les serveurs, un projet pour le code, des credentials pour les accès, et un job template pour tout lancer. Avec en prime l'historique de chaque exécution, des droits fins, des surveys pour les non-initiés, et des workflows pour orchestrer les déploiements complexes.