Un rôle Ansible est l'équivalent d'un module Terraform ou d'un chart Helm : une brique réutilisable qui packagde tâches, variables, templates, handlers et tests autour d'un objectif unique. Vous écrivez un rôle nginx une fois, vous le réutilisez dans 5 projets, vous le maintenez à un seul endroit.
Cette page explique pourquoi un rôle est supérieur à un long playbook, quand basculer du playbook au rôle, et ce que vous gagnez réellement (avec un exemple concret de refactoring).
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Le problème que les rôles résolvent : duplication, drift, code monolithique.
- La comparaison avec les modules Terraform et les charts Helm.
- Le ROI réel d'un refactoring playbook → rôle (avant/après).
- Quand basculer : critères pratiques pour décider.
- Anti-patterns : ce qu'il ne faut PAS mettre dans un rôle.
Le problème, un long playbook qui grossit
Section intitulée « Le problème, un long playbook qui grossit »Vous démarrez un projet pour automatiser un déploiement web. Première version : 50 lignes pour installer nginx. Trois mois plus tard, votre playbook.yml ressemble à ça :
---- name: Déployer toute l'infra web hosts: webservers become: true vars: nginx_version: "1.26.1" nginx_workers: 4 nginx_port: 80 php_version: "8.3" php_modules: - mysql - mbstring - curl db_host: db1.lab db_port: 5432 # ... 30 autres variables ...
tasks: # 50 tâches nginx - name: Installer nginx ansible.builtin.dnf: name: nginx state: present - name: Configurer nginx.conf ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf # ... 48 autres tâches nginx ...
# 30 tâches php-fpm - name: Installer PHP ...
# 40 tâches application métier ...
handlers: # 10 handlers ...500 lignes, 120 tâches, 30 variables, 10 handlers, 7 templates. Ce playbook fonctionne sur votre serveur de dev. Mais il pose 5 problèmes structurels.
Problème 1, Pas réutilisable
Section intitulée « Problème 1, Pas réutilisable »Demain, nouveau projet qui a aussi besoin de nginx. Vous copiez-collez les 50 tâches nginx dans le nouveau playbook. Drift garanti : à la première mise à jour de la config nginx, les deux versions divergent silencieusement.
Problème 2, Pas testable isolément
Section intitulée « Problème 2, Pas testable isolément »Vous voulez tester que nginx démarre correctement, indépendamment de PHP et de la base. Impossible avec ce playbook : pour tester nginx, vous devez rejouer toute la stack, attendre 5 minutes, et chercher dans le log si nginx a marché.
Problème 3, Mélange des responsabilités
Section intitulée « Problème 3, Mélange des responsabilités »Une modification urgente sur PHP nécessite de comprendre tout le contexte (nginx, base, app). Risque d'erreur élevé. Le diff Git est illisible : un changement sur la version PHP touche un fichier de 500 lignes que personne ne lit en entier.
Problème 4, Variables disséminées
Section intitulée « Problème 4, Variables disséminées »Les 30 variables sont au top du playbook. Trois mois plus tard, vous ne savez plus laquelle est vraie (par défaut), laquelle est forcée, laquelle vient d'un group_vars/. Le vars: du play écrase silencieusement vos group_vars/all.yml.
Problème 5, Pas distribuable
Section intitulée « Problème 5, Pas distribuable »Votre collègue veut nginx dans son projet. Comment lui donner ? Copier-coller 50 tâches ? Lui pousser un repo ? Aucun de ces deux flux n'est satisfaisant pour un partage à grande échelle.
La solution, un rôle par responsabilité
Section intitulée « La solution, un rôle par responsabilité »Refactorer en 3 rôles :
roles/├── nginx/ ← 50 tâches + 5 templates + 10 variables├── php-fpm/ ← 30 tâches + 3 templates + 8 variables└── app/ ← 40 tâches + 4 templates + 12 variablesLe playbook devient :
---- name: Déployer toute l'infra web hosts: webservers become: true
roles: - role: nginx vars: nginx_version: "1.26.1" nginx_workers: 4 - role: php-fpm vars: php_version: "8.3" - role: app vars: db_host: db1.lab20 lignes au lieu de 500. Lisible. Modulaire. Chaque rôle est :
- Réutilisable :
roles: - nginxdans un autre projet. - Testable isolément : Molecule sur le rôle nginx sans toucher PHP ni l'app.
- Versionnable indépendamment :
nginx@1.2.0,php-fpm@2.0.1dansrequirements.yml. - Documentable par un README clair (paramètres, exemples).
- Distribuable sur Galaxy ou un Automation Hub privé.
Comparaison avec d'autres outils IaC
Section intitulée « Comparaison avec d'autres outils IaC »Les rôles Ansible occupent dans l'écosystème la même niche que :
| Outil | Unité de réutilisation | Source |
|---|---|---|
| Ansible | Rôle | Galaxy, Automation Hub, GitHub |
| Terraform | Module | Terraform Registry, Git |
| Kubernetes | Helm chart | Artifact Hub, OCI registry |
| Pulumi | Component | Pulumi Registry, NPM/PyPI |
| Salt | Formula | Salt Formulas (GitHub) |
| Chef | Cookbook | Chef Supermarket |
| Puppet | Module | Puppet Forge |
Le concept est identique partout : un dossier structuré avec des conventions, une API d'entrée (variables/inputs), et un comportement encapsulé. Si vous avez utilisé un module Terraform, vous comprenez déjà 80 % d'un rôle Ansible, la syntaxe diffère mais la philosophie est identique.
ROI réel du refactoring, chiffres
Section intitulée « ROI réel du refactoring, chiffres »Voici le résultat concret d'un refactoring de production sur 5 projets utilisant nginx :
| Métrique | Avant (playbooks) | Après (rôle nginx + 5 projets) |
|---|---|---|
| Lignes de code totales (nginx) | 5 × 50 = 250 | 1 × 50 + 5 × 5 = 75 |
| Temps de mise à jour de la config nginx | 5 fichiers à éditer | 1 fichier à éditer |
| Risque de drift | Élevé | Nul (source unique) |
| Testabilité | 0 | Molecule isolé |
| Onboarding nouveau dev | Lit 500 lignes | Lit README.md du rôle |
Gain factuel : 60 % de code en moins, 100 % de drift en moins, testabilité de 0 à 100 %.
Quand basculer du playbook au rôle ?
Section intitulée « Quand basculer du playbook au rôle ? »Critères de décision simples :
- Le code va être réutilisé ailleurs (autre projet, autre environnement). → Rôle dès le départ.
- Le playbook dépasse 100 lignes et grossit. → Refactor en plusieurs rôles.
- Plusieurs équipes doivent collaborer. → Rôles (ownership clair).
- Vous voulez tester avec Molecule. → Rôle (Molecule fonctionne sur les rôles, pas les playbooks).
- Le code touche un service identifiable (nginx, postgres, vault). → Rôle par service.
À l'inverse, ne créez pas de rôle pour :
- Un playbook one-shot de migration unique (purge + import).
- Une glue très spécifique à un projet (reportez dans
tasks/du playbook). - Du code expérimental que vous n'êtes pas sûr de garder.
Anti-patterns à éviter
Section intitulée « Anti-patterns à éviter »Anti-pattern 1, Le rôle « base »/« common »
Section intitulée « Anti-pattern 1, Le rôle « base »/« common » »Tentation : un rôle common qui contient « tout ce que toutes les machines doivent avoir » (sshd, ntp, monitoring, users...). Problème : devient un fourre-tout ingérable. Préférer un rôle par responsabilité : sshd, ntp, monitoring, users. Plus long à écrire, infiniment plus maintenable.
Anti-pattern 2, Les rôles imbriqués profondément
Section intitulée « Anti-pattern 2, Les rôles imbriqués profondément »Un rôle webapp qui dépend du rôle nginx qui dépend du rôle tls qui dépend du rôle dns... 4 niveaux de profondeur. Debug = horreur. Préférer 2 niveaux maximum ou utiliser un playbook orchestrateur qui appelle les rôles à plat.
Anti-pattern 3, Variables hardcodées dans les tasks
Section intitulée « Anti-pattern 3, Variables hardcodées dans les tasks »# ❌ Mauvais- name: Configurer nginx ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf vars: nginx_version: "1.26.1" # ← hardcodé dans la taskLe rôle n'est plus paramétrable. Préférer defaults/main.yml :
# ✅ Bonnginx_version: "1.26.1"
# tasks/main.yml- name: Configurer nginx ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/nginx.confAnti-pattern 4, Tâches non idempotentes
Section intitulée « Anti-pattern 4, Tâches non idempotentes »# ❌ Mauvais- name: Vider le cache ansible.builtin.command: rm -rf /var/cache/nginx/*À chaque exécution, changed=true. Préférer un module dédié avec idempotence :
# ✅ Bon- name: Vider le cache ansible.builtin.file: path: /var/cache/nginx state: absent- name: Recréer le cache ansible.builtin.file: path: /var/cache/nginx state: directory mode: "0755"Anti-pattern 5, Pas de README ni d'argument_specs.yml
Section intitulée « Anti-pattern 5, Pas de README ni d'argument_specs.yml »Un rôle sans documentation est inutilisable par autrui, voire par vous-même 6 mois plus tard. Mandatory : README.md + meta/argument_specs.yml (validation des variables).
À retenir
Section intitulée « À retenir »- Un rôle = brique réutilisable testable distribuable. Équivalent d'un module Terraform.
- Refactor playbook → rôle dès que le code dépasse 100 lignes ou doit être réutilisé.
- ROI mesurable : 60 % de code en moins, 100 % de drift en moins, testabilité native.
- Un rôle = une responsabilité. Pas de rôle « base »/« common » fourre-tout.
- Anti-patterns : variables hardcodées, tâches non-idempotentes, pas de README.
- Imbrication max 2 niveaux, préférer un playbook orchestrateur.