Ansible Galaxy et collections

Tu viens d’apprendre à structurer ton code Ansible avec des roles. Mais soyons honnêtes : réécrire un role pour installer Nginx ou MySQL à chaque projet, c’est du temps perdu. Ansible Galaxy résout exactement ce problème — c’est le registre communautaire où des milliers de roles et collections sont prêts à l’emploi. Dans ce chapitre, tu vas apprendre à chercher, installer et gérer des roles Galaxy, comprendre la différence entre roles et collections, et déployer une stack LAMP complète en combinant roles communautaires et code custom.

Pourquoi Galaxy change la donne

Imagine que tu dois déployer Apache, MySQL et PHP sur 15 serveurs. Sans Galaxy, tu passes deux jours à écrire des roles from scratch, gérer les edge cases de chaque distro, tester les handlers de restart. Avec Galaxy, tu tires des roles maintenus par la communauté — certains avec des millions de téléchargements — et tu te concentres sur ce qui est spécifique à ton projet.

🔥 Cas réel : Une équipe SRE chez un éditeur SaaS a réduit son temps de bootstrap infra de 3 jours à 4 heures en passant de roles maison à des roles Galaxy de Jeff Geerling (geerlingguy.*). Le gain n’est pas juste en écriture — c’est en maintenance. Quand une CVE sort sur Apache, le role communautaire est patché en quelques heures par des dizaines de contributeurs.

💡 Tip DevOps : Galaxy, c’est le npm/pip d’Ansible. Même réflexe : avant de coder, cherche si ça existe déjà. Le role geerlingguy.docker a plus de 50 millions de téléchargements — il gère des cas que tu n’aurais jamais anticipés.

Comprendre roles et collections

Un role Galaxy est un composant autonome : il installe et configure un service précis (Nginx, PostgreSQL, Fail2ban…). Tu le tires depuis le registry et tu l’appelles dans ton playbook.

Depuis Ansible 2.10, les collections sont le format moderne. Une collection regroupe des roles, des modules et des plugins dans un seul package namespaced. Par exemple, community.docker contient le module docker_container, le module docker_image, et des roles associés — tout dans un namespace cohérent.

🧠 À retenir : Les roles standalone restent parfaits pour des tâches simples (installer un service). Les collections brillent quand tu as besoin de modules custom + roles + plugins qui fonctionnent ensemble. En 2026, privilégie les collections quand elles existent.

⚠️ Attention : Tous les roles Galaxy ne se valent pas. Avant d’installer un role, vérifie : le nombre de téléchargements, la date du dernier commit, la compatibilité avec ta distro, et s’il y a des tests CI. Un role abandonné depuis 2 ans, c’est une dette technique déguisée.

Commandes essentielles

Voici les commandes que tu utiliseras au quotidien pour interagir avec Galaxy. La recherche te permet de trouver des roles depuis le terminal sans ouvrir le navigateur :

# Chercher un role compatible Ubuntu
ansible-galaxy search nginx --platforms Ubuntu

# Installer un role (dernière version)
ansible-galaxy install geerlingguy.apache

# Installer une collection
ansible-galaxy collection install community.docker

# Lister les roles installés
ansible-galaxy list

En entreprise, tu ne vas jamais installer les roles un par un. Tu versionnes tes dépendances dans un fichier requirements.yml — exactement comme un package.json ou un requirements.txt. Voici un exemple typique qui mélange roles et collections :

---
roles:
  - name: geerlingguy.apache
    version: "3.3.0"
  - name: geerlingguy.mysql
    version: "4.0.0"
  - name: geerlingguy.php
    version: "5.0.0"

collections:
  - name: community.general
    version: ">=7.0.0"

Ensuite, une seule commande installe tout le nécessaire. Le flag --force est utile quand tu veux mettre à jour des roles déjà présents :

# Installer toutes les dépendances d'un coup
ansible-galaxy install -r requirements.yml

# Forcer la réinstallation (mise à jour)
ansible-galaxy install -r requirements.yml --force

💡 Tip DevOps : Commite toujours ton requirements.yml dans le repo. Ajoute roles/ dans le .gitignore — les roles Galaxy sont des dépendances, pas du code source. Comme tu ne commites pas node_modules/, tu ne commites pas les roles téléchargés.

Cas concret : stack LAMP en entreprise

Tu dois déployer une application PHP sur deux serveurs web avec un serveur MySQL dédié. Plutôt que de tout coder, tu combines des roles Galaxy pour l’infra et un role custom pour le déploiement applicatif spécifique.

Le playbook principal orchestre tout. Les roles Galaxy gèrent Apache, PHP et MySQL. Ton role custom app-deploy s’occupe du code métier — cloner le repo, installer les dépendances Composer, lancer les migrations :

---
- name: Configurer les serveurs web
  hosts: webservers
  become: true
  pre_tasks:
    - name: Mettre à jour le cache apt
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600
  roles:
    - geerlingguy.apache
    - geerlingguy.php
    - role: app-deploy
      vars:
        app_deploy_dir: /var/www/devopslab
        app_git_repo: "git@github.com:devopslab/app.git"

- name: Configurer la base de données
  hosts: dbservers
  become: true
  roles:
    - geerlingguy.mysql

La configuration des roles se fait via les variables dans group_vars/. Chaque role Galaxy bien conçu expose des variables documentées dans son README. Tu les surcharges selon ton contexte :

---
# group_vars/all.yml
apache_remove_default_vhost: true
apache_vhosts:
  - servername: "devopslab.ch"
    documentroot: "/var/www/devopslab"

mysql_root_password: "{{ vault_mysql_root_password }}"
mysql_databases:
  - name: app_production
    encoding: utf8mb4

php_version: "8.3"
php_packages:
  - "php8.3-cli"
  - "php8.3-mysql"
  - "php8.3-curl"
  - "php8.3-mbstring"

🔥 Cas réel : Ce pattern — roles Galaxy pour l’infra + role custom pour le métier — est utilisé par la majorité des équipes DevOps en production. L’astuce, c’est de ne jamais modifier un role Galaxy directement. Tu surcharges ses variables, point. Si tu as besoin de comportement custom, tu écris un role séparé qui s’exécute après.

Le déploiement suit toujours le même workflow en trois étapes — vérification syntaxique, dry run, puis exécution réelle :

# 1. Installer les dépendances Galaxy
ansible-galaxy install -r requirements.yml

# 2. Dry run pour vérifier sans rien casser
ansible-playbook site.yml --check --diff

# 3. Déployer pour de vrai
ansible-playbook site.yml -i inventory/production.yml

Pièges fréquents

Pas de version pinée dans requirements.yml. Sans version explicite, ansible-galaxy install tire la dernière release. Un jour ça marche, le lendemain une mise à jour casse tout. Pine toujours tes versions.

⚠️ Attention : Le piège classique du débutant — modifier directement les fichiers d’un role Galaxy dans roles/. Au prochain ansible-galaxy install --force, tes modifications sont écrasées. La bonne approche : surcharge les variables, ou crée un role wrapper qui inclut le role Galaxy et ajoute tes tasks.

Conflit de noms de variables. Deux roles Galaxy qui utilisent la même variable (port, user, config_path) vont se marcher dessus. C’est pour ça que les bons roles préfixent tout : nginx_port, mysql_user. Vérifie les defaults/main.yml des roles que tu installes.

Ignorer la compatibilité. Un role testé uniquement sur CentOS 7 ne fonctionnera probablement pas sur Ubuntu 24.04. Lis les meta/main.yml pour vérifier les plateformes supportées avant d’intégrer un role.

🧠 À retenir : Traite les roles Galaxy comme des dépendances externes. Version pinée, pas de modification directe, et un requirements.yml versionné dans Git. C’est la seule façon de garantir des déploiements reproductibles.

Exercice pratique

Mets en place un mini-projet qui utilise Galaxy :

1. Crée un dossier galaxy-lab/ avec un requirements.yml contenant le role geerlingguy.docker en version 7.4.0
2. Installe le role avec ansible-galaxy install -r requirements.yml -p roles/
3. Écris un playbook docker-setup.yml qui applique ce role sur localhost (en mode connection: local)
4. Lance un dry run avec --check pour vérifier que tout se passe bien
5. Bonus : ajoute la collection community.docker dans ton requirements.yml et utilise le module community.docker.docker_container pour lancer un conteneur Nginx après l’installation de Docker

💡 Tip DevOps : Pour tester sans risque sur ta machine, utilise --check --diff. Tu verras exactement ce qu’Ansible ferait sans rien appliquer. C’est ton filet de sécurité.

À retenir

• Ansible Galaxy est le registre communautaire — cherche avant de coder
• Collections = le format moderne (roles + modules + plugins dans un namespace)
• requirements.yml = ton fichier de dépendances, toujours versionné et commité
• Pine tes versions — jamais de latest implicite en production
• Ne modifie jamais un role Galaxy — surcharge les variables ou crée un wrapper
• Les meilleurs roles Galaxy (comme ceux de geerlingguy) sont battle-tested sur des millions de serveurs — profite de ce travail collectif

💡 Prochain chapitre : on plonge dans les variables avancées et les templates Jinja2 — le moteur qui rend Ansible capable de générer des configurations dynamiques adaptées à chaque environnement.