6.1 : Pourquoi des rôles ? Structure standard

Depuis la section 3, nos playbooks vivent dans un seul fichier. Pour un TP, c’est parfaitement suffisant. Mais imaginez le playbook Apache complet de Nordika : installation, template de VirtualHost, handler, vérification du port… Multipliez ça par cinq applications différentes (Apache, MariaDB, un reverse proxy, un serveur DNS…), et un seul fichier devient vite un mammouth de plusieurs centaines de lignes, difficile à relire, et surtout impossible à réutiliser ailleurs sans copier-coller.

C’est exactement le problème que les rôles résolvent.

Un rôle, c’est quoi concrètement ?

Un rôle regroupe tout ce qui concerne une seule responsabilité — installer et configurer Apache, par exemple — dans une structure de dossiers standardisée, indépendante du playbook qui l’appelle. Pensez-y comme un équipage spécialisé : l’équipage « Apache » sait tout faire pour Apache, peu importe sur quel vol (quel playbook) on le fait intervenir.

La structure standard

Ansible attend une arborescence précise pour qu’un rôle soit reconnu automatiquement :

roles/
└── apache/
    ├── tasks/
    │   └── main.yml
    ├── handlers/
    │   └── main.yml
    ├── templates/
    │   └── nordika.conf.j2
    ├── files/
    │   └── favicon.ico
    ├── vars/
    │   └── main.yml
    ├── defaults/
    │   └── main.yml
    └── meta/
        └── main.yml

Chaque dossier a un rôle précis (sans mauvais jeu de mots) :

Tous ces dossiers ne sont pas obligatoires — seul tasks/main.yml a vraiment besoin d’exister pour qu’un rôle fasse quelque chose. Le reste s’ajoute au fur et à mesure du besoin.

vars vs defaults : une distinction à ne pas manquer

C’est le piège classique du débutant qui découvre les rôles. Les deux dossiers contiennent des variables, mais avec une priorité très différente (souvenez-vous de l’ordre de précédence vu en 4.1) :

• defaults/main.yml : priorité très faible. C’est fait pour être surchargé facilement par un group_vars, un host_vars, ou une variable du playbook appelant.
• vars/main.yml : priorité plus élevée. Plus difficile à surcharger de l’extérieur — à réserver aux valeurs que le rôle ne veut pas voir changer facilement.

Concrètement : un port par défaut, une valeur qu’on s’attend à voir personnalisée selon le contexte → defaults. Une constante technique propre au fonctionnement interne du rôle → vars.

Comment un rôle s’utilise dans un playbook

Une fois le rôle écrit, le playbook qui l’utilise devient étonnamment court :

---
- name: Déployer l'infrastructure web de Nordika
  hosts: webservers
  become: yes
  roles:
    - apache

Tout ce qu’on avait écrit précédemment en plusieurs dizaines de lignes (installation, template, handler) est maintenant encapsulé dans le rôle apache, et ce même rôle peut être appelé depuis n’importe quel autre playbook, pour n’importe quel autre projet.

Le bénéfice concret pour Nordika

Reprenons l’histoire de la formation : si demain Nordika ouvre un nouveau site avec ses propres serveurs web, pas besoin de réécrire le playbook Apache depuis zéro. Le rôle apache se réutilise tel quel, avec éventuellement quelques defaults personnalisés pour ce nouveau site (un nom de domaine différent, par exemple).

Ce qu’il faut retenir

• Un rôle regroupe tout ce qui concerne une seule responsabilité, dans une structure de dossiers standardisée.
• Seul tasks/main.yml est vraiment indispensable ; le reste s’ajoute selon le besoin.
• defaults = facilement surchargeable, vars = plus figé — un choix à faire consciemment selon ce que le rôle doit exposer.
• Un playbook qui utilise des rôles devient court et lisible : roles: [apache] remplace des dizaines de lignes de tâches.

Dans la prochaine leçon, on crée notre premier rôle de A à Z, à partir du playbook Apache déjà écrit dans les sections précédentes.