Ansible et organization des roles

Dans Ansible, les rôles permettent d’organiser proprement la configuration d’un système en blocs réutilisables (au lieu d’un long playbook monolithique, on découpe la logique en rôles spécialisés). Chaque rôle suit une structure standard composée de plusieurs dossiers ayant chacun un rôle bien défini.

TL;DR

• tasks = actions
• defaults = variables
• templates = fichiers générés
• handlers = redémarrages
• roles = organization (tasks)

Tableau récapitulatif

Élément	Rôle	Contenu typique	Exemple
roles/	Contient tous les rôles du projet	Sous-dossiers de rôles	roles/mail/, roles/time/
<nom_du_role>/	Représente une fonctionnalité ou un service	Configuration complète d’un composant	mail, network, security
tasks/	Contient les actions exécutées	Installation, configuration, gestion de services	Installer Postfix, modifier un fichier
tasks/main.yml	Point d’entrée du rôle	Inclusion des autres tâches	include_tasks: postfix.yml
defaults/	Variables par défaut du rôle	Paramètres personnalisables	postfix_relayhost, chrony_config_location
handlers/	Actions déclenchées sur notification	Restart ou reload de services	Redémarrer chronyd ou postfix
templates/	Fichiers Jinja2 dynamiques	Fichiers de configuration générés	chrony.conf.j2, httpd.conf.j2
notify	Déclenche un handler après modification	Appel d’un redémarrage conditionnel	notify: restart_chrony
include_tasks	Charge un fichier de tâches	Découpage logique du rôle	include_tasks: rhel9.yml
include_vars	Charge des variables depuis un fichier	Variables spécifiques à un OS	include_vars: rhel9.yml

Résumé rapide

Dossier	Question à se poser
tasks/	Que dois-je faire ?
defaults/	Quelles valeurs utiliser ?
templates/	Quel fichier générer ?
handlers/	Que redémarrer après un changement ?
roles/	Quelle fonctionnalité gérer ?

Le dossier roles/

Le dossier roles/ est la racine de tous les rôles d’un projet Ansible. Chaque sous-dossier représente un rôle indépendant.

roles/
├── webserver/
├── database/
├── mail/

Le nom du rôle

Un rôle (ex : mail, time, network) représente une fonctionnalité ou un service.

Il contient toute la logique nécessaire pour installer, configurer et maintenir ce service.

Exemples

• mail → gestion du serveur mail (Postfix, Sendmail…)
• network → configuration réseau
• time → synchronisation NTP/Chrony
• security → configuration de sécurité
• packages → installation de paquets communs

Le dossier tasks/

C’est le cœur du rôle.

Il contient les actions exécutées sur les machines.

tasks/

Rôle

• Installer des packages
• Modifier des fichiers
• Démarrer ou arrêter des services
• Exécuter des commandes
• Appeler d’autres fichiers de tâches

Exemple

- name: Install Apache
  ansible.builtin.yum:
    name: httpd
    state: present

Le fichier main.yml dans tasks/

C’est le point d’entrée du rôle.

Ansible l’exécute automatiquement lorsqu’un rôle est appelé.

Il sert souvent à organiser les sous-tâches :

- name: Configure Apache
  ansible.builtin.include_tasks: apache.yml

- name: Configure PHP
  ansible.builtin.include_tasks: php.yml

---

Le dossier defaults/

Ce dossier contient les variables par défaut du rôle.

defaults/

Rôle

• Centraliser les variables
• Éviter les valeurs en dur dans les tâches
• Faciliter les personnalisations

Exemple

apache_port: 80
apache_user: apache

Puis dans une tâche :

- name: Open firewall port
  ansible.posix.firewalld:
    port: "{{ apache_port }}/tcp"
    state: enabled

Le dossier handlers/

Les handlers sont des tâches qui ne s’exécutent que lorsqu’elles sont appelées via notify.

handlers/

Rôle

• Redémarrer un service
• Recharger une configuration
• Exécuter une action uniquement lorsqu’un changement est détecté

Exemple

- name: Restart Apache
  ansible.builtin.service:
    name: httpd
    state: restarted

Appel depuis une tâche :

- name: Deploy configuration
  ansible.builtin.template:
    src: httpd.conf.j2
    dest: /etc/httpd/conf/httpd.conf
  notify:
    - restart_apache

Le dossier templates/

Les templates sont des fichiers Jinja2 permettant de générer des fichiers de configuration dynamiques.

templates/

Rôle

• Générer des fichiers de configuration
• Injecter des variables Ansible
• Adapter automatiquement les configurations

Exemple

Fichier :

templates/httpd.conf.j2

Contenu :

Listen {{ apache_port }}
ServerName {{ inventory_hostname }}

Déploiement :

- name: Deploy Apache configuration
  ansible.builtin.template:
    src: httpd.conf.j2
    dest: /etc/httpd/conf/httpd.conf

Fonctionnement global

Lorsqu’un rôle est exécuté :

1. Les variables sont chargées depuis defaults/
2. Les tâches sont exécutées depuis tasks/
3. Les templates sont déployés depuis templates/
4. Les handlers sont déclenchés si une tâche notifie un changement

Exemple de structure complète

roles/apache/
├── tasks/
│   └── main.yml
├── defaults/
│   └── main.yml
├── handlers/
│   └── main.yml
└── templates/
    └── httpd.conf.j2

Bonnes pratiques

Utiliser les rôles pour séparer les responsabilités

✔ Un rôle time pour la synchronisation horaire
✔ Un rôle mail pour Postfix
✔ Un rôle network pour la configuration réseau
X Éviter un rôle common contenant tout et n’importe quoi

Mettre les variables dans defaults

✔ Dans default/

postfix_relayhost: mail.example.org

X Dans les tâches.

line: relayhost = [mail.example.org]

Utiliser les handlers pour les redémarrages

✔ Dans les handlers

notify:
  - restart_chrony

X à chaque exécution du playbook.

state: restarted

Prévoir les différences entre OS

Cette approche facilite les évolutions futures tout en conservant une structure claire.

Exemple :

roles/time/
├── defaults/
│   ├── rhel6.yml
│   ├── rhel7.yml
│   ├── rhel8.yml
│   └── rhel9.yml
├── tasks/
│   ├── rhel6.yml
│   ├── rhel7.yml
│   ├── rhel8.yml
│   └── rhel9.yml
└── templates/
    ├── rhel6-ntp.conf.j2
    ├── rhel7-chrony.conf.j2
    ├── rhel8-chrony.conf.j2
    └── rhel9-chrony.conf.j2

Documentation

Ansible