Module package Ansible : installation agnostique multi-distro

ansible.builtin.package installe des paquets de manière agnostique : Ansible détecte automatiquement la distribution (ansible_pkg_mgr) et appelle dnf: sur RHEL, apt: sur Debian, pacman: sur Arch, zypper: sur SUSE. Idéal pour des rôles multi-distros.

Sur un parc 100% RHEL/RockyLinux/AlmaLinux, préférer dnf: qui expose des options spécifiques (enablerepo, security, bugfix).

Ce que vous allez apprendre

Quand utiliser package: (multi-distro) vs dnf:/apt: (mono-distro avec options).
Les 3 valeurs de state: : present, latest, absent.
Comment installer plusieurs paquets en une tâche (liste vs boucle).
Le piège state: latest sur des paquets critiques (mises à jour non maîtrisées).

Prérequis

Avoir un managed node avec become: true configuré.
Connaître la syntaxe d'un play (cf. Plays et tasks).

Installation simple

- name: Installer vim-enhanced
  ansible.builtin.package:
    name: vim-enhanced
    state: present

state: present est le défaut, n'installe que si absent. Si déjà installé, la tâche est ok (pas changed). C'est l'idempotence par défaut de package:.

Liste de paquets, une seule tâche, plusieurs paquets

- name: Installer plusieurs paquets en une fois
  ansible.builtin.package:
    name:
      - vim-enhanced
      - bash-completion
      - tree
      - htop
    state: present

Bien plus efficace qu'une boucle : Ansible fait un seul appel au gestionnaire (résout les dépendances en une passe). Avec loop:, chaque paquet déclenche un appel séparé, 4× plus lent sur des paquets indépendants.

Les 3 valeurs de `state:`

`state:`	Comportement	Usage
`present`	Installe si absent, n'upgrade pas	Défaut, installation idempotente
`latest`	Installe et upgrade vers la dernière version	Mise à jour systématique
`absent`	Supprime si présent	Nettoyage de paquets obsolètes

Attention à state: latest : sur un parc en production, c'est une mise à jour non maîtrisée au moindre run. Préférer state: present + un play de patch dédié (cf. dnf: security: true).

Désinstallation

- name: Supprimer telnet (en clair)
  ansible.builtin.package:
    name: telnet
    state: absent

state: absent est idempotent, si déjà absent, tâche ok. Utile pour les durcissements de poste (CIS Benchmark) : forcer l'absence de paquets dangereux comme telnet, rsh, xinetd.

Forcer le module sous-jacent, `use:`

Par défaut, Ansible auto-détecte (use: auto). Vous pouvez forcer :

- name: Forcer dnf meme si Ansible detecte autre chose
  ansible.builtin.package:
    name: htop
    state: present
    use: dnf

Cas réel : machine RHEL avec apt installé (rare, mais arrive sur des images Docker bizarres). use: dnf garantit que c'est dnf qui exécute.

Quand `package:` ne suffit plus

package: n'expose que les options communes à tous les gestionnaires. Pour utiliser :

enablerepo: / disablerepo:, passer à dnf:.
Mises à jour de sécurité uniquement (security: true), dnf: uniquement.
update_cache: (refresh apt/dnf cache), dnf: ou apt: directement.
Modules de groupe (@web-server sur RHEL), dnf: avec name: '@web-server'.

Idempotence et performance

package: consulte la base de données du gestionnaire pour savoir si le paquet est installé. Sur 100 hôtes, vérifier 10 paquets = 1000 requêtes DB locales. C'est rapide mais pas instantané.

Pour des plays courants (smoke test post-déploiement), grouper les paquets dans une seule tâche name: [...] comme montré plus haut, division par N du temps total.

Pièges courants

Symptôme	Cause	Fix
`Could not find a match` sur RHEL	Repo manquant ou désactivé	Activer le repo : passer à `dnf: enablerepo:`
`state: latest` upgrade un paquet critique en prod	Mise à jour non maîtrisée	Préférer `present` + cycle de patching dédié
Boucle `loop:` lente sur 50 paquets	Un appel au gestionnaire par paquet	Utiliser `name: [<liste>]` à la place
`package: name: vim` sur RHEL ne donne pas vim	`vim-enhanced` est le paquet réel sur RHEL	Vérifier le nom exact selon la distro

À retenir

package: = multi-distro, dnf:/apt: = mono-distro avec options spécifiques.
Liste de paquets dans name: [...] plutôt que boucle, 4× plus rapide.
state: latest est dangereux sur des paquets critiques en prod, préférer present + cycle de patching.
state: absent est l'outil de durcissement (CIS Benchmark), supprimer telnet, rsh, etc.

Mettre en pratique

L'intérêt de package: ne se voit qu'en écrivant une tâche qui doit tourner sans connaître le gestionnaire de la machine. Ce lab vous fait installer plusieurs paquets en un seul appel, puis en retirer un avec state: absent, le geste de durcissement à retenir. Vous y arbitrez aussi entre state: present et state: latest, dont l'écart se paie en production.

Module package : installation agnostique multi-distro

$ dsoxlab run modules-paquets-package

Environnement : VM·Durée : ~30 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-paquets-package
dsoxlab check modules-paquets-package

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

Pour aller plus loin

Module yum_repository : installer depuis un dépôt maison suppose de le déclarer d'abord, clé GPG comprise.
Module systemd_service : installer un paquet ne démarre rien, le service se pilote séparément.
Multi-distribution : les patterns qui prennent le relais quand le nom du paquet change selon la distribution.