Rôles : structurer un projet Ansible

Le problème d'un seul gros playbook

Un playbook de plusieurs centaines de lignes qui installe nginx, configure le pare-feu, déploie une application et gère les utilisateurs devient vite illisible et impossible à réutiliser partiellement. Les rôles découpent cette logique en unités réutilisables.

Structure d'un rôle

roles/
  nginx/
    tasks/main.yml       # les tâches à exécuter
    templates/nginx.conf.j2
    handlers/main.yml    # actions déclenchées par un changement (ex. redémarrer)
    defaults/main.yml    # valeurs par défaut des variables
    vars/main.yml         # variables du rôle

Utiliser un rôle dans un playbook

---
- name: Configurer les serveurs web
  hosts: web
  roles:
    - nginx
    - firewall
    - monitoring-agent

Ce playbook devient une simple liste de rôles à appliquer, chacun encapsulant sa propre logique, testable et réutilisable indépendamment sur d'autres projets.

Handlers : agir seulement si nécessaire

# tasks/main.yml
- name: Déployer la configuration nginx
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: Redémarrer nginx

# handlers/main.yml
- name: Redémarrer nginx
  service:
    name: nginx
    state: restarted

Le handler Redémarrer nginx ne s'exécute que si le fichier de configuration a réellement changé, évitant un redémarrage inutile à chaque exécution du playbook.

Cas concret

Une équipe a écrit un rôle nginx réutilisable pour un premier projet. Six mois plus tard, un nouveau projet a besoin exactement de la même configuration nginx standardisée : le rôle est copié tel quel (ou partagé via Ansible Galaxy), sans réécrire la logique depuis zéro, garantissant aussi la même qualité et les mêmes bonnes pratiques de sécurité déjà validées.

Erreurs fréquentes

• Ne jamais utiliser de handlers, redémarrant systématiquement un service à chaque exécution du playbook même sans changement, causant des coupures de service inutiles.
• Mélanger la logique de plusieurs responsabilités dans un seul rôle (nginx + base de données + pare-feu) : perd l'avantage de réutilisabilité indépendante.
• Copier-coller un rôle sans le versionner séparément : perte de traçabilité des évolutions et divergence progressive entre projets censés être identiques.

À retenir

• Les rôles découpent la logique Ansible en unités réutilisables et testables indépendamment.
• Un handler ne s'exécute que si une tâche associée a réellement produit un changement.
• Un rôle bien conçu peut être réutilisé tel quel sur plusieurs projets différents.

Mini-exercice

Un playbook redémarre nginx à chaque exécution, même quand rien n'a changé dans sa configuration, provoquant des coupures de service inutiles. Quelle fonctionnalité Ansible corrige ça ?

Réponse : un handler déclenché par notify, qui ne redémarre le service que si la tâche de déploiement de configuration a réellement modifié le fichier, pas à chaque exécution du playbook.