Ansible Devops

Ansible Galaxy : Réutiliser les Rôles et Collections de la Communauté

Exploitez Ansible Galaxy pour réutiliser des rôles et collections de la communauté. Installation, requirements.yml, collections populaires, publication et Automation Hub.
Walid ETTAYEB
15 min de lecture
Ansible Galaxy : Réutiliser les Rôles et Collections de la Communauté

Introduction : Ne Réinventez Pas la Roue

L'un des principes fondamentaux du développement logiciel est de ne pas réinventer la roue. Pourquoi passer des heures à écrire un rôle Ansible pour installer Docker, configurer PostgreSQL ou déployer un cluster Kubernetes quand quelqu'un l'a déjà fait — et probablement mieux que vous ne le feriez en partant de zéro ? C'est exactement la philosophie derrière Ansible Galaxy.

Ansible Galaxy est à la fois une plateforme communautaire (galaxy.ansible.com) et un outil en ligne de commande (ansible-galaxy) qui permettent de partager, découvrir et installer des rôles et des collections Ansible. Avec des milliers de rôles disponibles couvrant pratiquement tous les cas d'usage imaginables, Galaxy est un accélérateur incontournable pour vos projets d'automatisation.

Architecture en un coup d'œil

Diagramme - Ansible Galaxy : Réutiliser les Rôles et Collections de la Communauté

Dans cet article, nous allons explorer en profondeur l'écosystème Ansible Galaxy : comment chercher et installer des rôles et collections, comment gérer vos dépendances avec un fichier requirements.yml, et comment contribuer vous-même à la communauté en publiant vos propres rôles. Nous aborderons également les différences entre rôles et collections, ainsi que les collections les plus populaires à connaître.

Qu'est-ce qu'Ansible Galaxy ?

Ansible Galaxy se présente sous deux facettes complémentaires :

La plateforme web : galaxy.ansible.com

Le site galaxy.ansible.com est un hub communautaire où les développeurs du monde entier publient et partagent leurs rôles et collections Ansible. Vous y trouverez :

  • Des milliers de rôles couvrant l'installation et la configuration de pratiquement tous les logiciels courants (Nginx, Apache, Docker, PostgreSQL, MySQL, Redis, Elasticsearch, etc.).
  • Des collections regroupant des modules, plugins, rôles et documentation autour d'un thème ou d'une technologie (AWS, Azure, Docker, Kubernetes, etc.).
  • Des évaluations et statistiques : nombre de téléchargements, étoiles, dernière mise à jour, compatibilité avec les plateformes.
  • De la documentation : chaque rôle ou collection bien maintenue inclut un README détaillé avec les variables disponibles et des exemples d'utilisation.

Lorsque vous cherchez un rôle sur Galaxy, prêtez attention à plusieurs indicateurs de qualité :

  • Nombre de téléchargements : un rôle très téléchargé est généralement éprouvé.
  • Date de dernière mise à jour : un rôle non mis à jour depuis 3 ans risque d'être incompatible avec les versions récentes d'Ansible.
  • Présence de tests CI : les meilleurs rôles sont testés automatiquement avec Molecule et des pipelines CI/CD.
  • Qualité de la documentation : un README complet avec toutes les variables documentées est un signe de maturité.

L'outil en ligne de commande : ansible-galaxy

La commande ansible-galaxy est l'interface en ligne de commande qui interagit avec la plateforme Galaxy. Elle permet de chercher, installer, initialiser et gérer des rôles et des collections directement depuis votre terminal :

# Afficher l'aide générale
ansible-galaxy --help

# Aide spécifique aux rôles
ansible-galaxy role --help

# Aide spécifique aux collections
ansible-galaxy collection --help

Chercher des Rôles et des Collections

Recherche en ligne de commande

Vous pouvez chercher des rôles directement depuis votre terminal avec la commande ansible-galaxy search :

# Chercher des rôles liés à nginx
ansible-galaxy search nginx

# Chercher avec des filtres
ansible-galaxy search nginx --platforms Ubuntu
ansible-galaxy search nginx --author geerlingguy

# Afficher les détails d'un rôle spécifique
ansible-galaxy info geerlingguy.nginx

La commande ansible-galaxy info affiche des informations détaillées sur un rôle : description, auteur, licence, plateformes supportées, versions disponibles et dépendances.

Recherche sur le site web

Pour une recherche plus visuelle et interactive, rendez-vous sur galaxy.ansible.com. L'interface web permet de filtrer par type (rôle ou collection), par plateforme, par tag et par auteur. Vous pouvez également consulter le code source du rôle directement sur GitHub, ce qui est précieux pour évaluer la qualité du code avant de l'adopter.

Auteurs de référence

Certains auteurs sont particulièrement reconnus dans la communauté Ansible pour la qualité et la fiabilité de leurs rôles. En voici quelques-uns à connaître :

  • geerlingguy (Jeff Geerling) : auteur prolifique de dizaines de rôles très populaires (nginx, docker, php, mysql, postgresql, java, etc.). Ses rôles sont considérés comme des références en termes de bonnes pratiques.
  • robertdebock : maintient une large collection de rôles bien testés avec Molecule.
  • cloudalchemy : rôles spécialisés dans le monitoring (Prometheus, Grafana, Alertmanager).

Installer des Rôles depuis Galaxy

Installation simple

L'installation d'un rôle depuis Galaxy se fait en une seule commande :

# Installer un rôle depuis Galaxy
ansible-galaxy install geerlingguy.nginx

# Installer une version spécifique
ansible-galaxy install geerlingguy.nginx,3.1.0

# Installer dans un répertoire personnalisé
ansible-galaxy install geerlingguy.nginx --roles-path ./roles

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

Par défaut, les rôles sont installés dans le répertoire ~/.ansible/roles/. Vous pouvez modifier ce chemin par défaut dans votre fichier ansible.cfg :

# ansible.cfg
[defaults]
roles_path = ./roles:~/.ansible/roles

Installation depuis d'autres sources

La commande ansible-galaxy install ne se limite pas à la plateforme Galaxy. Elle supporte également d'autres sources :

# Depuis un dépôt Git
ansible-galaxy install git+https://github.com/user/mon-role.git

# Depuis un dépôt Git avec une version spécifique (tag, branche, commit)
ansible-galaxy install git+https://github.com/user/mon-role.git,v2.0.0

# Depuis une archive tar.gz
ansible-galaxy install https://example.com/roles/mon-role.tar.gz,v1.0,mon_role

# Depuis un dépôt Git privé via SSH
ansible-galaxy install git+ssh://git@github.com/user/mon-role-prive.git

Lister et supprimer des rôles

# Lister les rôles installés
ansible-galaxy list

# Supprimer un rôle
ansible-galaxy remove geerlingguy.nginx

Le Fichier requirements.yml

Pour un projet professionnel, il est impensable de gérer les dépendances manuellement. Le fichier requirements.yml joue le même rôle que package.json pour Node.js ou requirements.txt pour Python : il déclare toutes les dépendances du projet de manière reproductible.

Structure du fichier requirements.yml

Voici un fichier requirements.yml complet illustrant toutes les possibilités :

# requirements.yml
---
# ============================================
# Rôles
# ============================================
roles:
  # Rôle depuis Ansible Galaxy (syntaxe simple)
  - name: geerlingguy.docker
    version: "6.1.0"

  # Rôle depuis Galaxy avec alias
  - name: geerlingguy.nginx
    version: "3.1.0"

  # Rôle depuis Galaxy sans version fixe (dernière version)
  - name: geerlingguy.certbot

  # Rôle depuis Galaxy avec un nom personnalisé
  - name: geerlingguy.postgresql
    version: "3.4.0"

  # Rôle depuis un dépôt Git public
  - name: mon_role_custom
    src: https://github.com/mon-org/ansible-role-custom.git
    scm: git
    version: main

  # Rôle depuis un dépôt Git privé (via SSH)
  - name: role_interne
    src: git@gitlab.entreprise.com:infra/ansible-role-interne.git
    scm: git
    version: v2.3.1

  # Rôle depuis une archive HTTP
  - name: role_archive
    src: https://artifacts.entreprise.com/roles/mon-role-1.0.tar.gz

  # Rôle pour la sécurité
  - name: devsec.hardening
    version: "8.0.0"

  # Rôles pour le monitoring
  - name: cloudalchemy.prometheus
    version: "2.24.0"

  - name: cloudalchemy.grafana
    version: "0.17.0"

  - name: cloudalchemy.node_exporter
    version: "2.0.0"

# ============================================
# Collections
# ============================================
collections:
  # Collection communautaire générale
  - name: community.general
    version: ">=8.0.0"

  # Collection Docker
  - name: community.docker
    version: "3.8.0"

  # Collection pour les systèmes POSIX
  - name: ansible.posix
    version: "1.5.4"

  # Collection pour la cryptographie
  - name: community.crypto
    version: "2.18.0"

  # Collection AWS
  - name: amazon.aws
    version: "7.2.0"

  # Collection Azure
  - name: azure.azcollection
    version: "2.2.0"

  # Collection Kubernetes
  - name: kubernetes.core
    version: "3.0.0"

  # Collection MySQL
  - name: community.mysql
    version: "3.9.0"

  # Collection PostgreSQL
  - name: community.postgresql
    version: "3.3.0"

  # Collection depuis un dépôt Git privé
  - name: mon_namespace.ma_collection
    source: https://gitlab.entreprise.com/ansible/collections/ma-collection.git
    type: git
    version: main

  # Collection depuis un fichier tar.gz
  - name: entreprise.custom
    source: https://artifacts.entreprise.com/collections/entreprise-custom-1.0.0.tar.gz
    type: url

Installer les dépendances depuis requirements.yml

# Installer tous les rôles déclarés
ansible-galaxy install -r requirements.yml

# Installer toutes les collections déclarées
ansible-galaxy collection install -r requirements.yml

# Installer les deux en une seule commande (Ansible 2.10+)
ansible-galaxy install -r requirements.yml

# Forcer la réinstallation de tout
ansible-galaxy install -r requirements.yml --force

# Installer dans un chemin spécifique
ansible-galaxy install -r requirements.yml --roles-path ./roles
ansible-galaxy collection install -r requirements.yml -p ./collections

Il est recommandé d'intégrer l'installation des dépendances dans votre pipeline CI/CD et dans un Makefile pour simplifier l'onboarding des nouveaux membres de l'équipe :

# Makefile
.PHONY: setup deps lint run

setup: deps

deps:
	pip install ansible ansible-lint molecule molecule-docker
	ansible-galaxy install -r requirements.yml --force
	ansible-galaxy collection install -r requirements.yml --force

lint:
	ansible-lint playbooks/

run:
	ansible-playbook -i inventory/production playbooks/site.yml

Collections vs Rôles : Comprendre les Différences

Avec l'arrivée d'Ansible 2.10, les collections sont devenues le format de distribution privilégié. Mais quelle est la différence avec les rôles ? Et quand utiliser l'un plutôt que l'autre ?

Les rôles

Un rôle est une unité d'automatisation qui encapsule des tâches, variables, templates, fichiers et handlers pour accomplir une fonction spécifique (installer Nginx, configurer PostgreSQL, etc.). Les rôles existaient depuis les premières versions d'Ansible.

Caractéristiques des rôles :

  • Contiennent uniquement des tâches d'automatisation (pas de modules custom).
  • Structure standardisée (tasks/, handlers/, defaults/, etc.).
  • Peuvent être partagés sur Galaxy individuellement.
  • Ont un namespace basé sur l'auteur : geerlingguy.nginx.

Les collections

Une collection est un package plus large qui peut contenir des modules, plugins, rôles, documentation et playbooks. C'est le format de distribution moderne d'Ansible.

Caractéristiques des collections :

  • Peuvent contenir des modules (écritures de nouvelles fonctionnalités Ansible).
  • Peuvent contenir des plugins (filter, lookup, callback, connection, etc.).
  • Peuvent contenir des rôles (un ou plusieurs).
  • Ont un namespace structuré : namespace.collection (ex: community.docker).
  • Utilisent un système de versioning sémantique.
  • Sont le format recommandé depuis Ansible 2.10.

Tableau comparatif

Voici un résumé des différences clés :

  • Contenu : un rôle contient des tâches, variables et templates. Une collection peut contenir des modules, plugins, rôles et documentation.
  • Namespace : rôle = auteur.role, collection = namespace.collection.
  • Installation : rôle via ansible-galaxy install, collection via ansible-galaxy collection install.
  • Emplacement par défaut : rôles dans ~/.ansible/roles/, collections dans ~/.ansible/collections/.
  • Format recommandé : les collections sont le format moderne privilégié.
En pratique : pour partager de l'automatisation (tâches, templates, handlers), un rôle suffit. Si vous développez des modules custom, des plugins ou si vous voulez distribuer un ensemble cohérent de composants, utilisez une collection.

Installer et Utiliser des Collections

Installation de collections

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

# Installer une version spécifique
ansible-galaxy collection install community.docker:3.8.0

# Installer dans un chemin personnalisé
ansible-galaxy collection install community.docker -p ./collections

# Installer depuis un fichier tar.gz
ansible-galaxy collection install /chemin/vers/community-docker-3.8.0.tar.gz

# Lister les collections installées
ansible-galaxy collection list

# Vérifier si une collection est installée
ansible-galaxy collection list community.docker

Utiliser les modules d'une collection dans un playbook

Une fois une collection installée, vous utilisez ses modules avec leur nom complet qualifié (FQCN — Fully Qualified Collection Name) :

# playbook.yml
---
- name: Gérer des conteneurs Docker avec la collection community.docker
  hosts: docker_hosts
  become: true

  tasks:
    - name: S'assurer que Docker est installé
      ansible.builtin.apt:
        name: docker.io
        state: present

    - name: Démarrer le service Docker
      ansible.builtin.service:
        name: docker
        state: started
        enabled: true

    # Utilisation du module docker_container de community.docker
    - name: Lancer un conteneur Nginx
      community.docker.docker_container:
        name: mon_nginx
        image: nginx:latest
        state: started
        ports:
          - "8080:80"
        restart_policy: unless-stopped
        volumes:
          - /var/www/html:/usr/share/nginx/html:ro

    # Utilisation du module docker_network
    - name: Créer un réseau Docker
      community.docker.docker_network:
        name: mon_reseau
        driver: bridge

    # Utilisation du module docker_image
    - name: Tirer une image Docker
      community.docker.docker_image:
        name: redis
        tag: "7-alpine"
        source: pull

Vous pouvez également déclarer les collections utilisées au niveau du play avec le mot-clé collections: pour éviter de répéter le namespace complet :

# playbook.yml
---
- name: Gérer les conteneurs
  hosts: docker_hosts
  become: true
  collections:
    - community.docker

  tasks:
    - name: Lancer un conteneur
      docker_container:
        name: mon_app
        image: mon_image:latest
        state: started
Bonne pratique : utilisez toujours les FQCN (noms complets qualifiés) dans vos playbooks de production. Cela rend le code explicite et évite les conflits si deux collections définissent un module du même nom.

Les Collections Populaires à Connaître

Voici les collections les plus utilisées dans l'écosystème Ansible. Les connaître vous fera gagner un temps considérable.

community.general

C'est la collection "couteau suisse" d'Ansible. Elle contient des centaines de modules qui ne sont pas spécifiques à un éditeur ou une technologie particulière :

# Exemples de modules de community.general
- name: Gérer un dépôt APT
  community.general.apt_repo:
    repo: "ppa:ondrej/php"
    state: present

- name: Attendre qu'un service soit prêt
  community.general.wait_for:
    host: "{{ db_host }}"
    port: 5432
    delay: 5
    timeout: 60

- name: Gérer les tâches cron avec des noms
  community.general.cron:
    name: "Sauvegarde quotidienne"
    minute: "0"
    hour: "2"
    job: "/opt/scripts/backup.sh"

- name: Manipuler un fichier INI
  community.general.ini_file:
    path: /etc/application/config.ini
    section: database
    option: host
    value: db.example.com

- name: Gérer les paquets pip
  community.general.pip_package_info:
    clients: pip3

community.docker

Indispensable pour tout ce qui touche à Docker et Docker Compose :

# Modules clés de community.docker
- name: Gérer un conteneur
  community.docker.docker_container:
    name: app
    image: mon_app:latest
    state: started

- name: Gérer Docker Compose
  community.docker.docker_compose_v2:
    project_src: /opt/mon-projet
    state: present

- name: Construire une image
  community.docker.docker_image_build:
    name: mon_app
    tag: latest
    path: /opt/mon-projet

- name: Gérer les volumes
  community.docker.docker_volume:
    name: data_volume
    state: present

- name: Se connecter à un registry
  community.docker.docker_login:
    registry_url: https://registry.entreprise.com
    username: "{{ registry_user }}"
    password: "{{ registry_password }}"

ansible.posix

Collection pour les systèmes POSIX (Linux, macOS) avec des modules essentiels :

# Modules clés de ansible.posix
- name: Gérer les ACL de fichiers
  ansible.posix.acl:
    path: /var/www/html
    entity: www-data
    etype: user
    permissions: rwx
    state: present

- name: Configurer SELinux
  ansible.posix.selinux:
    state: enforcing
    policy: targeted

- name: Monter un système de fichiers
  ansible.posix.mount:
    path: /mnt/data
    src: /dev/sdb1
    fstype: ext4
    state: mounted

- name: Gérer les limites systèmes (ulimits)
  ansible.posix.sysctl:
    name: net.ipv4.ip_forward
    value: "1"
    sysctl_set: true
    state: present
    reload: true

- name: Synchroniser des fichiers (rsync)
  ansible.posix.synchronize:
    src: /opt/local/data/
    dest: /opt/remote/data/
    rsync_opts:
      - "--exclude=*.tmp"

community.crypto

Pour la gestion des certificats, clés et opérations cryptographiques :

# Générer une clé privée
- name: Créer une clé privée RSA
  community.crypto.openssl_privatekey:
    path: /etc/ssl/private/server.key
    size: 4096

# Générer un CSR
- name: Créer une demande de signature de certificat
  community.crypto.openssl_csr:
    path: /etc/ssl/certs/server.csr
    privatekey_path: /etc/ssl/private/server.key
    common_name: www.codeclan.fr
    organization_name: CodeClan

# Générer un certificat auto-signé
- name: Créer un certificat auto-signé
  community.crypto.x509_certificate:
    path: /etc/ssl/certs/server.crt
    privatekey_path: /etc/ssl/private/server.key
    csr_path: /etc/ssl/certs/server.csr
    provider: selfsigned

Autres collections notables

  • amazon.aws : modules pour AWS (EC2, S3, RDS, Lambda, etc.).
  • azure.azcollection : modules pour Microsoft Azure.
  • google.cloud : modules pour Google Cloud Platform.
  • kubernetes.core : modules pour Kubernetes (k8s, helm).
  • community.mysql : gestion de MySQL/MariaDB.
  • community.postgresql : gestion de PostgreSQL.
  • ansible.netcommon : modules réseau communs.
  • community.windows : modules pour Windows.

Créer un Rôle Galaxy-Compatible

Si vous souhaitez publier votre rôle sur Galaxy, il doit respecter certaines conventions pour être bien référencé et facilement utilisable par la communauté.

Initialiser le rôle

# Créer la structure du rôle
ansible-galaxy init mon_role_galaxy

# La structure créée est déjà compatible Galaxy
tree mon_role_galaxy/

Remplir les métadonnées (meta/main.yml)

Le fichier meta/main.yml est crucial pour Galaxy. Il fournit toutes les informations nécessaires au référencement de votre rôle :

# meta/main.yml
---
galaxy_info:
  role_name: mon_role_galaxy
  author: votre_pseudo_github
  description: "Rôle pour installer et configurer MonApplication sur Ubuntu et Debian"
  company: "CodeClan"
  license: "MIT"
  min_ansible_version: "2.14"

  platforms:
    - name: Ubuntu
      versions:
        - focal    # 20.04
        - jammy    # 22.04
        - noble    # 24.04
    - name: Debian
      versions:
        - bullseye # 11
        - bookworm # 12
    - name: EL      # Enterprise Linux (RHEL, CentOS, Rocky)
      versions:
        - "8"
        - "9"

  galaxy_tags:
    - system
    - configuration
    - web
    - nginx

  # Liens utiles
  issue_tracker_url: https://github.com/votre_user/ansible-role-mon-role/issues
  repository: https://github.com/votre_user/ansible-role-mon-role

dependencies: []

Écrire un README de qualité

Un bon README est essentiel pour l'adoption de votre rôle. Voici les sections recommandées :

# README.md — Structure recommandée
# Mon Rôle Galaxy

## Description
Brève description du rôle et de ce qu'il fait.

## Prérequis
- Ansible >= 2.14
- Systèmes supportés : Ubuntu 22.04+, Debian 12+

## Variables du rôle
| Variable | Défaut | Description |
|----------|--------|-------------|
| `app_port` | `8080` | Port d'écoute |
| `app_user` | `appuser` | Utilisateur système |

## Dépendances
Liste des rôles dont celui-ci dépend.

## Exemple d'utilisation
Playbook d'exemple.

## Tests
Comment lancer les tests (Molecule).

## Licence
MIT

## Auteur
Votre nom

Préparer le dépôt Git

Galaxy s'appuie sur les dépôts GitHub pour héberger les rôles. Voici les conventions à suivre :

# Convention de nommage du dépôt
# Format : ansible-role-{nom_du_role}
# Exemple : ansible-role-nginx

# Initialiser le dépôt Git
cd mon_role_galaxy
git init
git add .
git commit -m "feat: initial role structure"

# Créer un tag de version (sémantique)
git tag -a v1.0.0 -m "Version 1.0.0 - Initial release"

# Pousser vers GitHub
git remote add origin git@github.com:user/ansible-role-mon-role.git
git push origin main --tags

Publier sur Ansible Galaxy

Connexion et import

Pour publier un rôle sur Galaxy, vous devez vous connecter avec votre compte GitHub :

  1. Rendez-vous sur galaxy.ansible.com et connectez-vous avec GitHub.
  2. Accédez à "My Content" dans votre profil.
  3. Cliquez sur "Add Content" et sélectionnez votre dépôt GitHub.
  4. Galaxy importera automatiquement votre rôle en analysant le meta/main.yml.

Vous pouvez aussi importer via la ligne de commande :

# Se connecter (nécessite un token GitHub)
# Récupérez votre token sur galaxy.ansible.com > Preferences > API Token

# Importer le rôle
ansible-galaxy role import votre_user ansible-role-mon-role

# Vérifier l'import
ansible-galaxy role info votre_user.mon_role

Mettre à jour un rôle publié

Pour publier une nouvelle version, il suffit de créer un nouveau tag Git et de relancer l'import :

# Faire vos modifications
git add .
git commit -m "feat: add SSL support"

# Créer un nouveau tag
git tag -a v1.1.0 -m "Version 1.1.0 - Added SSL support"
git push origin main --tags

# Relancer l'import sur Galaxy
ansible-galaxy role import votre_user ansible-role-mon-role

Publier une collection

La publication d'une collection suit un processus légèrement différent :

# Construire la collection (crée un fichier tar.gz)
ansible-galaxy collection build

# Publier sur Galaxy
ansible-galaxy collection publish ./mon_namespace-ma_collection-1.0.0.tar.gz --api-key YOUR_API_KEY

Ansible Automation Hub

En plus d'Ansible Galaxy (communautaire et gratuit), Red Hat propose Ansible Automation Hub, une plateforme de distribution de contenu Ansible certifié et supporté par Red Hat.

Différences entre Galaxy et Automation Hub

  • Galaxy : communautaire, gratuit, contenu non certifié. Tout le monde peut publier. Idéal pour les projets personnels et les équipes qui évaluent et testent elles-mêmes les rôles.
  • Automation Hub : contenu certifié par Red Hat, support commercial, accès via souscription Red Hat Ansible Automation Platform. Idéal pour les entreprises qui ont besoin de garanties de qualité et de support.

Configurer Automation Hub

Pour utiliser Automation Hub comme source de collections, configurez votre fichier ansible.cfg :

# ansible.cfg
[galaxy]
server_list = automation_hub, galaxy

[galaxy_server.automation_hub]
url = https://console.redhat.com/api/automation-hub/content/published/
auth_url = https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token = VOTRE_TOKEN_AUTOMATION_HUB

[galaxy_server.galaxy]
url = https://galaxy.ansible.com/

Avec cette configuration, Ansible cherchera d'abord les collections sur Automation Hub (contenu certifié), puis sur Galaxy (contenu communautaire) en fallback.

Private Automation Hub

Les entreprises peuvent également déployer un Private Automation Hub en interne pour héberger leurs propres collections et rôles privés. C'est une solution idéale pour :

  • Distribuer du contenu Ansible interne sans le rendre public.
  • Contrôler exactement quelles versions de collections sont disponibles pour les équipes.
  • Servir de proxy/cache pour Galaxy et Automation Hub.
# ansible.cfg avec Private Automation Hub
[galaxy]
server_list = private_hub, automation_hub, galaxy

[galaxy_server.private_hub]
url = https://hub.entreprise.com/api/galaxy/content/published/
token = VOTRE_TOKEN_PRIVE

[galaxy_server.automation_hub]
url = https://console.redhat.com/api/automation-hub/content/published/
token = VOTRE_TOKEN_RH

[galaxy_server.galaxy]
url = https://galaxy.ansible.com/

Bonnes Pratiques pour Gérer les Dépendances Galaxy

Versionner les dépendances

Épinglez toujours les versions de vos dépendances dans requirements.yml. Sans version fixe, une mise à jour automatique d'un rôle ou d'une collection pourrait casser votre infrastructure :

# BIEN : versions fixées
roles:
  - name: geerlingguy.docker
    version: "6.1.0"

collections:
  - name: community.docker
    version: "3.8.0"

# À ÉVITER : pas de version
roles:
  - name: geerlingguy.docker  # Quelle version sera installée ?

Intégrer dans le pipeline CI/CD

# .gitlab-ci.yml
---
stages:
  - deps
  - lint
  - test
  - deploy

install_dependencies:
  stage: deps
  script:
    - pip install ansible ansible-lint
    - ansible-galaxy install -r requirements.yml --force
    - ansible-galaxy collection install -r requirements.yml --force
  artifacts:
    paths:
      - roles/
      - collections/

lint:
  stage: lint
  script:
    - ansible-lint playbooks/
  needs:
    - install_dependencies

test:
  stage: test
  script:
    - molecule test
  needs:
    - install_dependencies

Auditer régulièrement les dépendances

Planifiez des revues régulières de vos dépendances Galaxy :

  • Vérifiez si des mises à jour de sécurité sont disponibles.
  • Testez les nouvelles versions en staging avant de les déployer en production.
  • Remplacez les rôles abandonnés par des alternatives maintenues.
  • Envisagez d'internaliser (fork) les rôles critiques pour réduire la dépendance externe.

Ne pas commiter les dépendances

Ajoutez les répertoires de dépendances à votre .gitignore, comme vous le feriez avec node_modules/ :

# .gitignore
roles/geerlingguy.*
roles/devsec.*
roles/cloudalchemy.*
collections/
*.retry

Exemple Pratique : Projet Complet avec Galaxy

Mettons tout en pratique avec un projet Ansible complet utilisant des rôles et collections Galaxy pour déployer une application web :

# requirements.yml
---
roles:
  - name: geerlingguy.docker
    version: "6.1.0"
  - name: geerlingguy.nginx
    version: "3.1.0"
  - name: geerlingguy.certbot
    version: "4.1.0"
  - name: geerlingguy.postgresql
    version: "3.4.0"
  - name: devsec.hardening
    version: "8.0.0"

collections:
  - name: community.general
    version: "8.0.0"
  - name: community.docker
    version: "3.8.0"
  - name: community.postgresql
    version: "3.3.0"
  - name: ansible.posix
    version: "1.5.4"
# playbooks/site.yml
---
- name: Configuration de base et sécurité
  hosts: all
  become: true
  roles:
    - role: devsec.hardening

- name: Déployer l'application web
  hosts: webservers
  become: true

  pre_tasks:
    - name: Mettre à jour le cache APT
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

  roles:
    - role: geerlingguy.docker
    - role: geerlingguy.nginx
      vars:
        nginx_remove_default_vhost: true
        nginx_vhosts:
          - listen: "80"
            server_name: "app.codeclan.fr"
            extra_parameters: |
              location / {
                  proxy_pass http://127.0.0.1:3000;
                  proxy_set_header Host $host;
                  proxy_set_header X-Real-IP $remote_addr;
              }
    - role: geerlingguy.certbot
      vars:
        certbot_auto_renew: true
        certbot_create_if_missing: true
        certbot_certs:
          - domains:
              - app.codeclan.fr

  tasks:
    - name: Déployer l'application avec Docker
      community.docker.docker_container:
        name: mon_application
        image: "registry.entreprise.com/mon-app:latest"
        state: started
        restart_policy: unless-stopped
        ports:
          - "3000:3000"
        env:
          DATABASE_URL: "postgresql://{{ db_user }}:{{ db_pass }}@{{ db_host }}:5432/{{ db_name }}"
          NODE_ENV: production

- name: Configurer la base de données
  hosts: databases
  become: true
  roles:
    - role: geerlingguy.postgresql
      vars:
        postgresql_databases:
          - name: mon_app_db
        postgresql_users:
          - name: mon_app_user
            password: "{{ vault_db_password }}"
            db: mon_app_db
            priv: "ALL"
# Déployer le tout
ansible-galaxy install -r requirements.yml
ansible-galaxy collection install -r requirements.yml
ansible-playbook -i inventory/production playbooks/site.yml --ask-vault-pass

Conclusion

Ansible Galaxy est un accélérateur de productivité indispensable pour tout praticien Ansible. En combinant des rôles communautaires éprouvés avec vos propres rôles métier, vous construisez une automatisation robuste sans partir de zéro. Les collections, format moderne de distribution, enrichissent encore cet écosystème en apportant des modules, plugins et rôles dans des packages cohérents.

Les points clés à retenir :

  • Utilisez requirements.yml pour déclarer et versionner toutes vos dépendances.
  • Préférez les collections (format moderne) et utilisez les FQCN dans vos playbooks.
  • Évaluez la qualité des rôles avant de les adopter (mises à jour, tests, documentation).
  • Contribuez à la communauté en publiant vos propres rôles et collections.
  • En entreprise, envisagez Ansible Automation Hub ou un Private Automation Hub pour le contenu certifié.

Dans le prochain article, nous aborderons un sujet critique pour la sécurité de vos déploiements : Ansible Vault. Vous apprendrez à chiffrer vos secrets (mots de passe, clés API, certificats) pour ne jamais les exposer en clair dans vos fichiers Ansible.

Écrit par

Walid ETTAYEB

Passionné par la technologie, je transforme ma passion en expertise.

Vous pourriez aussi aimer

Appuyez sur ESC pour fermer.

Parcourir les articles par tags populaires

Devops Self-Hosting Sécurité Terraform Ansible Scripts Astuces
Vous vous êtes abonné avec succès à CodeClan
Parfait ! Ensuite, complétez le paiement pour obtenir un accès complet à tout le contenu premium.
Erreur ! Impossible de s'inscrire. Lien invalide.
Bienvenue ! Vous vous êtes connecté avec succès.
Erreur ! Impossible de se connecter. Veuillez réessayer.
Succès ! Votre compte est entièrement activé, vous avez maintenant accès à tout le contenu.
Erreur ! Le paiement Stripe a échoué.
Succès ! Vos informations de facturation sont mises à jour.
Erreur ! La mise à jour des informations de facturation a échoué.