Une collection est l'unité de distribution moderne d'Ansible : elle empaquette modules, plugins (filter, lookup, inventory, callback...), rôles, playbooks, docs et tests sous un même namespace versionné. Depuis ansible-core 2.10, les collections remplacent définitivement les rôles standalone Galaxy v1 ; en 2026, Galaxy NG (Galaxy v3) ne supporte que les collections. Cette section couvre le parcours collections RHCE 2026 : FQCN, requirements.yml multi-sources, création d'une collection custom, pipeline CI, et migration rôle → collection.
Aller droit au but
Section intitulée « Aller droit au but » 🚀 Découvrir une collection ansible-galaxy collection list/info, FQCN, structure plugins/roles
📚 requirements.yml multi-sources Galaxy + Git + URL tarball, pinning strict, signatures GPG
🎯 Créer une collection custom init + module Python + build, ansible-test sanity au vert
🔥 Pipeline CI matrice GitHub Actions / GitLab CI durcis 2026, matrice ansible-core × Python
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre ce qu'est une collection (vs rôle), structure
plugins/,roles/,meta/runtime.yml. - FQCN (Fully Qualified Collection Name) obligatoire en 2026 (
ansible.builtin.copy,community.general.archive). - Installer des collections depuis Galaxy, Git, URL tarball, chemin local via
requirements.yml. - Vérifier l'intégrité avec
ansible-galaxy collection verifyet signatures GPG. - Créer votre propre collection avec un module Python custom + rôle + playbook.
- Tester la collection en CI avec
ansible-test sanity --docker. - Migrer un rôle standalone vers une collection sans casser les playbooks downstream.
Prérequis
Section intitulée « Prérequis »Avant cette section, vous devez avoir validé :
- Découvrir Ansible : architecture, FQCN intro.
- Premiers pas : premier playbook.
- Modules essentiels :
copy,template,dnf. - Rôles Ansible : structure d'un rôle.
Mon retour d'expérience — pour ceux qui veulent comprendre
Section intitulée « Mon retour d'expérience — pour ceux qui veulent comprendre »Si l'une des cartes en haut de page vous a déjà orienté, vous êtes parti sur le bon pied. La suite de cette page s'adresse à ceux qui veulent comprendre la philosophie de cette section : pourquoi le passage aux collections n'est pas négociable en 2026, pourquoi le FQCN est un investissement et non un caprice, et pourquoi je refuse certains raccourcis classiques.
J'ai migré plusieurs projets Ansible legacy de rôles Galaxy v1 vers collections entre 2021 et 2025. Le verdict : plus on attend, plus la migration coûte cher. Les playbooks downstream qui pointent vers geerlingguy.nginx au lieu de community.general.* finissent par casser silencieusement quand Galaxy NG retire le support v1. Les sections qui suivent compilent ce que je n'aurais jamais accepté de relâcher dans un projet qui se respecte.
Pourquoi les collections ont remplacé les rôles standalone
Section intitulée « Pourquoi les collections ont remplacé les rôles standalone »Trois raisons motivent le passage aux collections en 2026 :
- Plusieurs ressources sous un même namespace versionné : un rôle Galaxy v1 ne distribuait qu'une chose. Une collection en distribue N (modules + rôles + plugins + playbooks) avec un cycle de release unique.
- FQCN obligatoire : éviter les conflits de noms entre auteurs (
ansible.posix.firewalldvscommunity.general.firewalld). Le namespace est propriété d'un mainteneur, comme un username GitHub. - Galaxy NG (Pulp-based, 2026) ne supporte plus les rôles standalone Galaxy v1. Toute nouvelle distribution doit être en collection.
La boîte à outils du mainteneur
Section intitulée « La boîte à outils du mainteneur »| Outil | Rôle |
|---|---|
ansible-galaxy collection init | Génère la structure complète conforme |
ansible-galaxy collection install -r requirements.yml | Installe les dépendances |
ansible-galaxy collection list / info | Inspecte ce qui est installé |
ansible-galaxy collection verify | Vérifie l'intégrité (checksums, signatures GPG) |
ansible-galaxy collection build | Produit le tarball publiable |
ansible-galaxy collection publish | Pousse sur Galaxy (token API) |
ansible-test sanity --docker default | Validation FQCN + doc + types + PEP8 |
ansible-test units --docker | Tests pytest sur modules Python |
antsibull-changelog release | Génère CHANGELOG.rst depuis fragments |
Galaxy public vs Automation Hub — choix 2026
Section intitulée « Galaxy public vs Automation Hub — choix 2026 »| Critère | Galaxy public | Automation Hub (AAP 2.5/2.6) |
|---|---|---|
| Coût | Gratuit | Inclus subscription AAP |
| Contenu | community.* ouvertes | Certified Content Red Hat + partenaires + Validated Content |
| Support | Aucun | SLA Red Hat sur certified |
| Signatures GPG | Optionnel | Activé par défaut |
| Scan vulnérabilités | Non | Trivy + scans CVE auto |
| Cas d'usage 2026 | Open-source, dev, formation | Production entreprise sous contrat |
Décision pratique :
- Formation, dev, projets open-source → Galaxy public.
- Production entreprise sous contrat Red Hat → Automation Hub (collections certifiées + scannées).
- Hub privé interne → Galaxy NG self-hosted (Pulp-based, gratuit), pour airgap ou multi-équipe.
Ce que je défends pour les collections
Section intitulée « Ce que je défends pour les collections »Cinq positions tranchées que cette section assume :
- FQCN partout, sans exception, dès la première ligne d'un nouveau playbook.
ansible.builtin.copyest plus long de 14 caractères mais évite les shadowing silencieux quand une collection installée plus tard redéfinitcopy. Lisibilité + futur-proofing — c'est aussi un objectif RHCE 2026. requirements.ymlversionné dans Git, dépendances pinnées par version (version: 1.2.3) ou par SHA Git (version: a3f9b2c). Jamaismainoulatesten production : drift garanti, debug impossible 6 mois plus tard.ansible-test sanityau vert avant tout commit sur la branche principale. Pas de relâchement : un avertissement de doc manquante aujourd'hui devient une erreur bloquante demain. Le pre-commit hook règle le problème dès l'écriture.- Migration progressive
rôle → collectionavecplugin_routing.redirect. Renommer un module sans redirect casse silencieusement les playbooks downstream — vos utilisateurs n'apprécieront pas. Leredirect+ warning donne 1-2 cycles de release pour migrer. - Galaxy public pour open-source, Automation Hub pour entreprise. Pas de mélange. Une collection certifiée Red Hat scannée Trivy sur Hub apporte un SLA que Galaxy public ne donnera jamais. Choisissez l'outil selon le contexte, pas selon l'habitude.
Ce que je vous interdis
Section intitulée « Ce que je vous interdis »Cinq anti-patterns observés en revue de code et en mission :
- Pinner par branche Git (
version: main) en production. Drift garanti : la branche évolue sous vos pieds, les playbooks « marchent » jusqu'au jour où ils ne marchent plus, sans changelog côté votre repo. Tag ou SHA, point. - Renommer un module ou un plugin sans
plugin_routing.redirect. Vous cassez tous les playbooks downstream sans signal. Le redirect + warning est non négociable pour toute évolution publique. build_ignore:mal configuré → tarball gonflé par.git/,.venv/, secrets de tests, fichiers IDE. La collection devient lourde à télécharger et leak des données sensibles. Vérifier après chaquebuild.- Oublier
meta/runtime.ymldès qu'on ajoute un module Python custom.ansible-test sanityéchoue, la collection refuse l'install. Mandatory dès le premier module. - Publier sans
CHANGELOG.rst. Les utilisateurs ne savent pas ce qui change, n'osent pas mettre à jour.antsibull-changelog+ fragments par PR génère un changelog propre — non négociable pour tout projet sérieux.
Le parcours en 5 étapes
Section intitulée « Le parcours en 5 étapes »Étape 1 — Comprendre
Section intitulée « Étape 1 — Comprendre » Découvrir une collection ansible-galaxy collection list/info, FQCN, structure plugins/roles/meta.
Étape 2 — Installer
Section intitulée « Étape 2 — Installer » requirements.yml multi-sources Galaxy + Git + URL tarball + local. Pinning strict. Signatures GPG.
Étape 3 — Construire
Section intitulée « Étape 3 — Construire » Créer une collection custom ansible-galaxy collection init, galaxy.yml, module Python, build, ansible-test sanity.
Étape 4 — Tester en CI
Section intitulée « Étape 4 — Tester en CI » Pipeline CI matrice ansible-core × Python GitHub Actions + GitLab CI durcis 2026 (SHA pinning, permissions: {}, ansible-test sanity).
Étape 5 — Migrer
Section intitulée « Étape 5 — Migrer » Migrer un rôle standalone vers une collection meta/runtime.yml plugin_routing.redirect pour rétrocompatibilité du nom court + warning.
À retenir
Section intitulée « À retenir »- Une collection =
plugins/+roles/+playbooks/+meta/runtime.yml+galaxy.yml. - FQCN obligatoire en 2026 :
namespace.collection.plugin. requirements.yml= source unique des dépendances (Galaxy/Git/URL/dir + pinning).ansible-galaxy collection initgénère la structure complète conforme.ansible-test sanity --docker default= validation pré-publication.plugin_routing.redirectdansmeta/runtime.yml= rétrocompatibilité après renaming.- Galaxy public pour open-source, Automation Hub pour production entreprise.
Prochaines étapes
Section intitulée « Prochaines étapes » Commencer : découvrir une collection ansible-galaxy collection list/info, structure standard, FQCN.
requirements.yml complet Galaxy + Git + signatures GPG. Pattern reproductible.
Créer sa collection custom init + module Python + build, ansible-test sanity au vert.
Pipeline CI GitHub Actions + GitLab CI durcis 2026, matrice ansible-core × Python.