Ansible Galaxy : installer et réutiliser un rôle communautaire

On vient d’écrire notre propre rôle Apache de A à Z. C’était l’exercice pédagogique nécessaire pour comprendre la mécanique. Mais en pratique, une question mérite d’être posée avant d’écrire le moindre rôle : quelqu’un l’a-t-il déjà fait, et bien fait ?

C’est exactement le rôle d’Ansible Galaxy : une plateforme communautaire qui héberge des milliers de rôles et collections prêts à l’emploi, mainteus par leurs auteurs, testés sur de multiples distributions, et réutilisables directement dans vos playbooks.

Chercher un rôle existant

Avant de coder, un réflexe simple : chercher sur galaxy.ansible.com si un rôle solide existe déjà pour votre besoin. Pour Docker, par exemple, le rôle geerlingguy.docker (de Jeff Geerling, auteur bien connu dans l’écosystème Ansible) est une référence largement utilisée et maintenue.

Installer un rôle avec `ansible-galaxy`

ansible-galaxy install geerlingguy.docker

Par défaut, le rôle s’installe dans un dossier partagé du système (~/.ansible/roles en général), accessible depuis n’importe quel projet Ansible sur la machine.

Utiliser le rôle installé

Une fois installé, il s’utilise exactement comme un rôle qu’on aurait écrit soi-même :

---
- name: Installer Docker sur les serveurs Nordika
  hosts: docker-servers
  become: yes
  roles:
    - geerlingguy.docker

Le rôle s’occupe de tout : dépôt officiel Docker, installation du paquet, démarrage du service, gestion multi-distribution — un travail déjà fait, testé, et maintenu par la communauté, plutôt que réinventé par vos soins.

`requirements.yml` : lister ses dépendances proprement

Installer des rôles un par un en ligne de commande fonctionne, mais devient vite ingérable dès que votre projet dépend de plusieurs rôles externes. La bonne pratique consiste à les lister dans un fichier requirements.yml, versionné avec votre projet dans Git :

# requirements.yml
---
roles:
  - name: geerlingguy.docker
    version: "6.1.0"
  - name: geerlingguy.apache
    version: "5.0.0"

Et on installe tout d’un coup :

ansible-galaxy install -r requirements.yml

Remarquez le paramètre version : c’est important de l’épingler plutôt que de laisser Ansible installer « la dernière version disponible ». Sans version fixée, un rôle qui fonctionnait hier peut changer de comportement du jour au lendemain, sans que vous ayez touché à quoi que ce soit dans votre propre projet — un problème de reproductibilité qu’on retrouve dans beaucoup d’écosystèmes logiciels, pas seulement Ansible.

Les collections : au-delà des simples rôles

Galaxy distribue aussi des collections : des paquets qui regroupent des modules, des rôles, et parfois des plugins, autour d’un même thème (par exemple community.mysql, qu’on a déjà croisé dans le lab découverte de cette formation pour gérer MariaDB). On les installe de la même façon :

ansible-galaxy collection install community.mysql

Ou, toujours mieux, listées dans requirements.yml :

# requirements.yml
---
roles:
  - name: geerlingguy.docker
    version: "6.1.0"

collections:
  - name: community.mysql
    version: "3.9.0"

ansible-galaxy install -r requirements.yml

Auditer un rôle avant de l’utiliser en production

Un rôle communautaire reste du code écrit par un tiers, exécuté avec des droits élevés (become: yes) sur vos serveurs. Avant de l’utiliser sur un environnement sensible, quelques réflexes simples :

Consulter le nombre d’étoiles/téléchargements et la date de dernière mise à jour sur Galaxy.
Parcourir rapidement tasks/main.yml sur le dépôt GitHub du rôle — ça reste du YAML lisible, pas un binaire opaque.
Préférer les rôles maintenus par des auteurs reconnus (comme Jeff Geerling) plutôt qu’un rôle abandonné depuis trois ans.

Ce qu’il faut retenir

Avant d’écrire un rôle, vérifiez si un rôle communautaire solide existe déjà sur Galaxy.
ansible-galaxy install <nom> pour un rôle ponctuel, requirements.yml + ansible-galaxy install -r requirements.yml dès que le projet en dépend durablement.
Toujours épingler une version précise dans requirements.yml, pour éviter qu’un rôle change de comportement sans que vous l’ayez décidé.
Un rôle externe reste du code tiers exécuté avec des droits élevés : un minimum de vérification avant de l’utiliser en production reste un bon réflexe.