Module Ansible filesystem : créer un système de fichiers Linux

Le module community.general.filesystem crée un système de fichiers sur une partition ou un volume logique : ext4, xfs, btrfs, f2fs, swap. C'est l'étape après la partition (cf. parted ou un LV LVM) et avant le mount. Public visé : intermédiaires Ansible RHEL/Debian, candidats RHCSA. Cette page couvre la création (ext4, xfs), le resize (étendre un fs après agrandissement de la partition), les différences entre fstypes et les pièges idempotence (un fs créé reste créé, on ne le détruit pas par accident).

Ce que vous allez apprendre

• Créer un filesystem ext4 ou xfs sur une partition.
• Choisir entre ext4, xfs, btrfs selon le cas d'usage.
• Étendre un filesystem après agrandissement du device sous-jacent.
• Forcer la création (force: true) sur un device qui contient déjà un fs.
• Diagnostiquer les pièges d'idempotence.

Prérequis

• Collection community.general installée :

  ansible-galaxy collection install community.general

• Outils userspace présents sur le nœud (mkfs.ext4, mkfs.xfs, etc.), installés par défaut sur RHEL et Debian.

• Un device cible : partition (/dev/vdb1), LV (/dev/vg_data/lv_app), ou disque entier.

• Privilèges root (become: true).

Le module ne détruit jamais un fs existant par défaut

Filesystem est protégé contre la destruction accidentelle : si le device contient déjà un fs (même différent du fstype demandé), la task n'écrase pas sauf force: true. C'est volontaire, destruction de données = catastrophe.

Création standard, ext4 ou xfs

- name: Créer un fs ext4 sur /dev/vdb1
  community.general.filesystem:
    fstype: ext4
    dev: /dev/vdb1
    state: present

Comportement :

• Si /dev/vdb1 n'a aucun fs → mkfs.ext4 /dev/vdb1 est exécuté, task changed.
• Si /dev/vdb1 a déjà un fs ext4 → task ok (idempotent).
• Si /dev/vdb1 a un autre fs (xfs, btrfs) → task failed sauf si force: true.
• Si /dev/vdb1 n'existe pas → task failed.

Pour xfs :

- name: Créer un fs xfs sur /dev/vg_data/lv_app
  community.general.filesystem:
    fstype: xfs
    dev: /dev/vg_data/lv_app
    state: present

ext4 vs xfs vs btrfs, quel choix

Fstype	Forces	Faiblesses	Quand l'utiliser
ext4	Mature, très large compat, fsck rapide	Pas de checksums	Workloads classiques, SSD systèmes
xfs	Default RHEL 9/10, scale jusqu'à 8 EiB, perf en parallèle	Pas de shrink (extension only)	Stockage de données, workloads I/O parallèles
btrfs	Snapshots natifs, checksums, RAID intégré	Plus complexe, recovery parfois capricieux	Postes de travail (Fedora default), backup
swap	(pas un vrai fs)	Sans objet	Espace de pagination

Glissez pour voir

Sur RHEL 8/9/10, le default est xfs, c'est ce que l'installeur RHEL choisit pour /, /home, /var. Sur Debian/Ubuntu, c'est ext4.

Cas d'usage :

• /, /home sur RHEL → xfs (par cohérence avec l'installeur).
• /, /home sur Debian → ext4.
• /var/lib/postgresql/, /var/lib/mysql/ → xfs (perf I/O parallèles).
• /boot/efi → vfat (ESP doit être FAT).
• Swap → fstype: swap.

Création swap

- name: Créer un fs swap
  community.general.filesystem:
    fstype: swap
    dev: /dev/vdb2

- name: Activer le swap
  ansible.builtin.command: swapon /dev/vdb2
  args:
    creates: /proc/swaps        # idempotence simple

- name: Ajouter le swap dans /etc/fstab
  ansible.posix.mount:
    src: /dev/vdb2
    path: none
    fstype: swap
    opts: sw
    state: mounted

fstype: swap lance mkswap. Pour activer le swap au boot, l'ajouter dans /etc/fstab via ansible.posix.mount.

Étendre un filesystem (resize)

Cas typique : la partition ou le LV a été agrandi, on veut propager l'agrandissement au filesystem.

# 1. Agrandir le LV
- name: Créer le volume logique lv_app
  community.general.lvol:
    vg: vg_data
    lv: lv_app
    size: 100g
    resizefs: false        # PAS de resize côté lvol : on le fait via filesystem

# 2. Étendre le fs sur le device agrandi
- name: Formater lv_app
  community.general.filesystem:
    fstype: xfs
    dev: /dev/vg_data/lv_app
    resizefs: true

resizefs: true lance la commande appropriée selon le fstype :

• ext4 → resize2fs /dev/... (online si fs monté).
• xfs → xfs_growfs /<mountpoint> (le fs doit être monté pour étendre xfs).
• btrfs → btrfs filesystem resize ....

xfs ne se shrink pas

xfs ne supporte pas la réduction. Si vous devez réduire un volume xfs, il faut :

1. Sauvegarder les données.
2. Détruire le fs.
3. Réduire le device (LV ou partition).
4. Recréer le fs.
5. Restaurer les données.

C'est un trade-off xfs vs ext4, ext4 supporte le shrink offline (resize2fs <device> <size> avec fs démonté).

Forcer la création, force: true

Pour écraser un fs existant (perte de données, assumée) :

- name: Reformatter une partition (perte de données accepté)
  community.general.filesystem:
    fstype: xfs
    dev: /dev/vdb1
    force: true

À utiliser uniquement dans des cas explicites :

• Lab jetable.
• Re-provisionnement complet d'un device après destroy.
• Migration de fstype (rare, généralement migre les données vers un nouveau device).

Pièges courants

Symptôme	Cause	Solution
device <X> is mounted, not allowed	Device monté, mkfs refuse	Démonter avec ansible.posix.mount: state=unmounted
cannot resize sur xfs démonté	xfs s'étend uniquement online	Monter le fs d'abord puis lancer le resize
wrong fs type, bad option, bad superblock au mount	Fs créé mais corrompu	Re-créer avec force: true puis re-mount
Mauvaise UUID, fstab ne match plus	Re-création du fs change l'UUID	Re-mettre à jour /etc/fstab avec la nouvelle UUID après recréation
mkfs.<fs>: command not found	Outils userspace manquants	dnf install xfsprogs e2fsprogs btrfs-progs selon le fs
Idempotence cassée sur device dynamique	Device path change (LVM, multipath)	Utiliser un identifiant stable (UUID, /dev/disk/by-uuid/...)
Module manquant	Collection community.general non installée	ansible-galaxy collection install community.general

Glissez pour voir

À retenir

• community.general.filesystem crée un fs sur un device, pas une partition (utiliser parted avant).
• Default RHEL = xfs, default Debian/Ubuntu = ext4.
• xfs ne shrink pas, choix engageant, à connaître avant de créer.
• resizefs: true étend automatiquement le fs après agrandissement du device.
• force: true écrase un fs existant, destruction de données assumée, à n'utiliser qu'en cas explicite.
• Le module ne démonte pas, c'est à vous de démonter avant si nécessaire.
• Enchaîner toujours partition → filesystem → mount dans un rôle.

Mettre en pratique

Le choix d'un fstype est engageant, et la protection contre l'écrasement ne se comprend bien qu'en la déclenchant. Ce lab vous fait formater deux partitions, l'une en ext4, l'autre en xfs, puis vérifier ce que blkid retourne réellement. Vous provoquez ensuite l'échec attendu en changeant de type sans force: true, avant de forcer la recréation en connaissance de cause.

Lab pratique

Module filesystem : créer un système de fichiers

$ dsoxlab run modules-rhel-filesystem

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-rhel-filesystem
dsoxlab check modules-rhel-filesystem

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

• Module stat : contrôler l'état réel d'un périphérique avant de le formater.
• Modules assert et fail : transformer ce contrôle en précondition bloquante, avec un message d'erreur clair.
• Écrire ses premiers rôles : ranger la séquence partition, filesystem et montage dans un rôle réutilisable.

×

📖 Voir la documentation →