Modules Ansible : FQCN, collections et cartographie pour le RHCE

Un module Ansible est l'unité atomique d'exécution — la brique qui fait réellement quelque chose sur le managed node : copier un fichier, installer un paquet, démarrer un service, ouvrir un port, créer un utilisateur. Le moteur Ansible orchestre, mais ce sont les modules qui agissent. Cette section couvre les modules essentiels au RHCE EX294 2026, regroupés en 7 sous-sections thématiques, après avoir posé les concepts transverses (FQCN, collections, idempotence, ansible-doc) qui s'appliquent à tous.

Aller droit au but

🚀 Trouver le bon module Méthode + cartographie + rappel sécurité supply chain — à lire en priorité

📚 Fichiers : copy, file, template Manipuler fichiers, dossiers, archives — la base de toute config Linux

🎯 Paquets & services package, dnf, systemd_service, cron — le cœur opérationnel RHCE

🔥 Système RHEL : firewalld + SELinux + LVM Sécurité et stockage — la spécialité RHCE qui distingue Ansible RHEL d'Ubuntu

Ce que vous allez apprendre

Le concept de module et sa différence avec une commande shell.
La notion de FQCN (ansible.builtin.dnf, community.general.sudoers) — obligatoire en 2026.
Les 3 grandes collections que vous utiliserez 90 % du temps : ansible.builtin, ansible.posix, community.general.
Comment trouver un module via ansible-doc (autorisé en examen RHCE).
La carte des modules par catégorie pour vous orienter.

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 FQCN n'est pas un caprice esthétique, pourquoi je refuse command:/shell: quand un module dédié existe, et pourquoi ansible-doc mérite plus d'attention qu'on ne lui en donne.

J'ai vu des projets Ansible passer de 5 minutes à 20 minutes d'exécution simplement parce que personne n'avait migré vers les FQCN — la résolution dynamique des modules courts ralentit considérablement sur grand parc. J'ai aussi vu des playbooks « marcher » 6 mois puis casser silencieusement quand une nouvelle collection installée a redéfini un module court. Cette section compile les habitudes que je n'aurais jamais accepté de relâcher dans un projet sérieux.

Qu'est-ce qu'un module Ansible

Un module est un petit programme (généralement Python) qu'Ansible transfère sur le managed node, exécute avec des paramètres précis, puis rapatrie un résultat structuré (JSON). C'est ce résultat qui dit si la tâche est ok, changed, ou failed.

- name: Installer nginx
  ansible.builtin.dnf:
    name: nginx
    state: present

Trois propriétés distinguent un module d'un script bash classique :

L'idempotence : exécuter le module deux fois donne le même résultat. Si nginx est déjà installé, le module retourne ok au lieu de changed. Pas de double-installation.
Le retour structuré : Ansible reçoit un dict (changed, msg, rc, stdout, ...) directement utilisable dans register: et when:.
L'agnostisme distrib : un module comme package: détecte automatiquement dnf, apt, pacman selon la cible — même playbook sur Debian et RHEL.

Règle absolue : un module dédié l'emporte toujours sur un command: ou shell:. Si vous voyez ansible.builtin.shell: dnf install -y nginx, vous savez qu'il faut le réécrire avec ansible.builtin.dnf:.

FQCN — Fully Qualified Collection Name

Depuis Ansible 2.10, chaque module a un nom complet sous la forme <namespace>.<collection>.<module>. C'est le FQCN :

Forme courte (déconseillée)	FQCN (mandatory en 2026)
`dnf:`	`ansible.builtin.dnf:`
`copy:`	`ansible.builtin.copy:`
`firewalld:`	`ansible.posix.firewalld:`
`sudoers:`	`community.general.sudoers:`

Pourquoi c'est obligatoire : sans FQCN, Ansible doit deviner quelle collection contient le module — ambigu si plusieurs collections définissent firewalld. Avec FQCN, zéro ambiguïté, le code reste fonctionnel quand de nouvelles collections s'ajoutent.

ansible-lint --profile production échoue sur tout module sans FQCN. C'est aussi un reflex évalué au RHCE EX294 2026.

Les 3 collections que vous utiliserez 90 % du temps

Collection	Contenu	Installation
`ansible.builtin`	Modules cœur livrés avec `ansible-core` (copy, file, dnf, apt, systemd, user, group, lineinfile...)	Inclus, rien à installer
`ansible.posix`	Modules POSIX/Linux (firewalld, mount, sysctl, selinux, authorized_key, sysvinit)	`ansible-galaxy collection install ansible.posix`
`community.general`	Très large catalogue communautaire (sudoers, lvol, lvg, filesystem, pamd, hostname, nmcli...)	`ansible-galaxy collection install community.general`

Trois autres collections apparaissent ponctuellement dans le parcours :

community.crypto : génération de clés et certificats X.509.
community.hashi_vault : intégration HashiCorp Vault / OpenBao pour les secrets.
kubernetes.core : gestion de manifests K8s depuis Ansible.

Au RHCE 2026, vous utilisez quasi exclusivement les trois premières. Le requirements.yml d'un projet RHCE type ressemble à :

---
collections:
  - name: ansible.posix
    version: ">=1.5.0"
  - name: community.general
    version: ">=8.0.0"

Comment choisir le bon module

Face à un nouveau besoin, trouver le module adapté est un réflexe à acquérir. La page Trouver le bon module détaille la méthode complète — recherche, évaluation qualité d'une collection, rappel sécurité supply chain (typosquatting, takeover, signatures) et garde-fous opérationnels (mirror privé, pinning).

Trouver un module avec `ansible-doc`

ansible-doc est votre seule documentation autorisée pendant l'examen RHCE — apprenez à l'utiliser vite et bien.

ansible-doc ansible.builtin.copy            # Doc complète d'un module
ansible-doc -l                              # Liste tous les modules
ansible-doc -l ansible.posix                # Liste les modules d'une collection
ansible-doc -s ansible.builtin.copy         # Snippet YAML prêt à copier
ansible-doc -t lookup file                  # Doc d'un lookup plugin

Le snippet -s est le plus précieux en examen — il génère un YAML annoté que vous adaptez en quelques secondes :

$ ansible-doc -s ansible.builtin.copy
- name: Copy files to remote locations
  ansible.builtin.copy:
    src:                # source path
    dest:               # destination path (required)
    owner:              # name of the user
    group:              # name of the group
    mode:               # permissions (e.g. '0644')

Cartographie de la section

Les modules sont regroupés par finalité métier plutôt que par ordre alphabétique — c'est plus pratique en révision RHCE.

Fichiers et templates

Manipulation de fichiers, dossiers, archives — la base de toute config sous Linux.

Module copy Copier un fichier du control node vers le managed node, avec content/validate/backup

Module file Créer/supprimer fichiers, dossiers, liens, gérer owner/group/mode

Module blockinfile Insérer un bloc marqué dans un fichier de config sans le réécrire entièrement

Module lineinfile Modifier une seule ligne dans un fichier — ajouter, remplacer via regexp, supprimer

Module replace Substituer un motif (regex) partout dans un fichier sans réécrire la ligne entière

Module fetch Récupérer un fichier depuis le managed node vers le control node

archive et unarchive Compresser et décompresser des archives (tar, zip, gz) avec idempotence

Paquets et services

Installer des paquets, démarrer des services, planifier des cron jobs.

Module package Installation agnostique multi-distro (dnf/apt/pacman détectés automatiquement)

Module dnf — options Contrôle fin RHEL : enablerepo, security, exclude, allow_downgrade

Module yum_repository Déclarer un dépôt RPM (EPEL, Docker CE) avec sa clé GPG, gérer les dépôts désactivés

Module systemd_service Démarrer, activer, masquer, recharger un service systemd

Module cron Planifier une tâche dans /etc/cron.d/ avec idempotence sur le name:

Multi-distribution Patterns when ansible_os_family + vars/RedHat.yml pour parc hétérogène

Utilisateurs et groupes

Gestion des comptes locaux, clés SSH, sudoers — au programme du RHCE.

Module user Créer/modifier/supprimer un compte local, gérer password_hash, home, shell

Module group Gérer les groupes Linux, primary vs supplementary

Module authorized_key Déployer une clé SSH publique dans ~/.ssh/authorized_keys avec exclusive

Module sudoers Créer une règle sudoers dans /etc/sudoers.d/ avec validation visudo

Système (RHEL et Linux)

Sécurité, stockage, paramètres kernel — le cœur RHEL du RHCE.

Module firewalld Ouvrir un service ou un port avec ansible.posix.firewalld (zone, permanent)

Module SELinux Mode (enforcing/permissive), booléens (seboolean), contextes (sefcontext)

Module sysctl Régler net.ipv4.ip_forward, vm.swappiness, kernel.shmmax avec persistance

Module mount Monter/démonter un filesystem, persister dans /etc/fstab

Module parted Créer/supprimer une partition GPT ou MBR (alignement, flags lvm/boot/esp)

Module filesystem Créer un fs ext4, xfs, btrfs, swap sur une partition ou un LV (resize online)

LVM (lvg + lvol + filesystem) Pipeline complet : VG → LV → mkfs → mount, avec idempotence à chaque étape

Module hostname Changer le hostname avec persistance (hostnamectl) — RHEL et Debian

Module reboot Rebooter et attendre la reconnexion SSH avec test_command et timeout

Module getent Interroger NSS (passwd, group, hosts) sans passer par le shell

Réseau et téléchargement

Récupérer une URL, interroger une API REST, télécharger un installateur.

Module get_url Télécharger un fichier depuis HTTP(S), valider checksum, gérer reprise

Module uri Appeler une API REST (GET/POST/PUT/DELETE), parser la réponse JSON

Diagnostic et contrôle

Tester l'état avant d'agir, valider après, attendre une condition.

Module stat Inspecter fichier/dossier (existence, mtime, mode, checksum) avant action

Module find Rechercher des fichiers par âge, taille, pattern — alternative ansible à find Unix

Modules assert et fail Valider une précondition (assert) ou échouer explicitement (fail) avec message

Modules wait_for et pause Attendre un port, un fichier, une chaîne, ou une durée fixe avant de continuer

Module service_facts Auditer l'état (running/enabled) de tous les services systemd en une tâche

Compléments

Modules transversaux qui ne rentrent pas dans une catégorie unique : exécution directe, utilitaires, Windows.

raw, command, shell, script Exécution directe en dernier recours — quand aucun module dédié n'existe

debug, setup, add_host, group_by Utilitaires transversaux : debug, gather_facts, inventaire dynamique, wait_for_connection

Windows (WinRM, OpenSSH) Piloter un parc Windows avec ansible.windows et community.windows

La place des modules dans la RHCE EX294

Les modules sont au cœur de l'examen — environ 60 % des tâches du RHCE consistent à choisir le bon module et à le paramétrer correctement.

Catégorie d'objectif RHCE	Sous-section couvrante
Gérer les paquets logiciels	Paquets et services
Gérer les services	Paquets et services
Configurer les utilisateurs et groupes	Utilisateurs et groupes
Configurer le pare-feu et SELinux	Système
Gérer le stockage (LVM, FS, mount)	Système
Manipuler des fichiers de config	Fichiers et templates
Planifier des tâches (cron, timer)	Paquets et services
Récupérer des données via HTTP/API	Réseau
Diagnostiquer un état	Diagnostic

Ce que je défends pour les modules

Cinq positions tranchées que cette section assume :

FQCN partout, sans dérogation. ansible.builtin.copy même dans un script jetable. L'habitude se prend dès la première ligne ou ne se prend jamais. C'est un objectif RHCE 2026 explicite, et un gain de performance mesurable sur grand parc.
Module dédié, toujours. Avant d'écrire command: dnf install nginx, chercher ansible-doc -l | grep dnf. Le module dédié gère idempotence, check mode, diff. command:/shell: sont des aveux d'échec — acceptables seulement quand vraiment aucun module n'existe.
ansible-doc plus que la doc web. La doc embarquée correspond exactement à votre version installée. À l'examen RHCE, vous n'avez pas internet — ansible-doc -s <module> est votre seule planche de salut. Apprenez à le lire vite.
requirements.yml versionné dès le premier projet. ansible.posix et community.general sont nécessaires pour 90 % des cas réels. Pinning strict (version: ">=1.5.0"), pas de latest. Reproductibilité non négociable.
Vérifier avant de copier-coller un module IA. Les LLM inventent des modules qui n'existent pas (ansible.builtin.docker_container au lieu de community.docker.docker_container). ansible-doc <fqcn> confirme ou réfute en 2 secondes — c'est gratuit.

Ce que je vous interdis

Cinq erreurs typiques sur les modules — chacune source de bug ou d'échec à l'examen :

Modules non FQCN. firewalld: au lieu de ansible.posix.firewalld:. Erreur résolution si la collection n'est pas installée, performance dégradée, et ansible-lint --profile production échoue. FQCN partout, point.
command: ou shell: quand un module dédié existe. Cas typique : command: systemctl restart nginx au lieu de ansible.builtin.systemd_service: name=nginx state=restarted. Le module dédié gère idempotence et check mode — command: perd les deux.
state: installed, state: started, state: running au lieu des valeurs canoniques (present, started). Chaque module a son vocabulaire — ansible-doc <module> liste les valeurs valides. Inventer une valeur = failed: invalid state.
Recopier un snippet IA sans ansible-doc. Le module n'existe pas, l'option a été renommée, ou la collection requise n'est pas dans requirements.yml. Vérifier coûte 2 secondes, débugger coûte 20 minutes.
Ignorer le rappel supply chain Galaxy. Pinner les versions, vérifier les signatures GPG, préférer un mirror privé en entreprise. Une collection compromise vous donne shell root sur tout votre parc — c'est le type d'incident qui termine une carrière.

À retenir

Un module = unité atomique idempotente. Toujours préférer un module dédié à command: ou shell:.
FQCN obligatoire en 2026 : <namespace>.<collection>.<module>.
3 collections = 90 % de votre travail : ansible.builtin, ansible.posix, community.general.
ansible-doc est votre seule doc autorisée au RHCE — maîtrisez -s, -l, -t.
7 sous-sections thématiques : fichiers, paquets-services, utilisateurs, système, réseau, diagnostic, compléments.

Prochaines étapes

Trouver le bon module Méthode + cartographie + rappel sécurité supply chain — à lire en priorité

Module package La porte d'entrée : installer un paquet sur Debian, RHEL, Arch avec un seul module

Module copy Le module le plus utilisé du parcours — copier un fichier avec idempotence

raw, command, shell, script Le dernier recours, à connaître pour ne pas l'utiliser à mauvais escient