3.3 : L’idempotence expliquée concrètement

On a croisé ce mot depuis le tout début de la formation, sans jamais s’y arrêter vraiment. Le moment est venu : l’idempotence est le concept qui distingue réellement Ansible d’un simple script, et c’est probablement la notion la plus importante de toute cette formation.

La définition, en une phrase

Une opération est idempotente si le fait de la répéter plusieurs fois produit exactement le même résultat que de l’exécuter une seule fois.

Reprenons l’analogie de la tour de contrôle : demander à un avion déjà posé d’atterrir une deuxième fois n’a aucun effet — il est déjà au sol. C’est ça, l’idempotence : répéter l’ordre ne change rien à l’état final, parce que l’état voulu est déjà atteint.

Un exemple concret, étape par étape

Reprenons le playbook Apache de la leçon précédente :

- name: Installer Apache
  ansible.builtin.apt:
    name: apache2
    state: present

Première exécution, sur un serveur tout neuf :

TASK [Installer Apache] *******************************
changed: [nrd-web1]

Apache n’était pas installé, Ansible l’installe, changed: true. Logique.

Deuxième exécution, sur le même serveur, sans rien modifier :

TASK [Installer Apache] *******************************
ok: [nrd-web1]

Cette fois, ok et non changed. Ansible a vérifié l’état actuel du serveur, a constaté qu’Apache était déjà installé, et n’a rien fait. Aucune commande apt install n’a été relancée en coulisses.

C’est cette vérification systématique, avant d’agir, qui fait toute la différence.

Pourquoi c’est si important en pratique

Rappelez-vous l’histoire racontée dans l’introduction de cette formation : un script shell qui plante à moitié parcours, laissant le parc dans un état incohérent. Avec un playbook idempotent, ce scénario catastrophe change complètement de nature :

• Vous pouvez relancer un playbook qui a échoué en cours de route, sans craindre de « réinstaller par-dessus » ou de dupliquer une action. Les tâches déjà en état correct seront ignorées (ok), seules celles qui restent à faire (ou qui ont échoué) seront rejouées.
• Vous pouvez exécuter le même playbook chaque nuit, en toute confiance, sans craindre qu’il modifie inutilement des machines déjà conformes.
• Vous pouvez donner le même playbook à un collègue, sur un parc dans un état différent du vôtre, et il convergera vers le même résultat, peu importe le point de départ.

changed, ok, failed : les trois états à connaître

À chaque tâche, Ansible affiche l’un de ces trois statuts :

Un playbook idempotent, rejoué sur un parc déjà conforme, doit afficher uniquement des ok, zéro changed. Si vous voyez du changed à chaque exécution, sans que rien n’ait changé sur la machine entre-temps, c’est le signe que quelque chose est cassé dans votre playbook — on reverra ce diagnostic plus loin dans la formation.

--check : simuler sans agir

Ansible propose un mode « à blanc » très utile pour vérifier l’idempotence sans prendre le moindre risque :

ansible-playbook playbook_apache.yaml -i inventaire.yaml --check

En mode --check, Ansible simule l’exécution : il indique ce qu’il aurait changé, sans rien modifier réellement sur les machines. Parfait pour vérifier, avant une exécution réelle en production, qu’un playbook ne va rien casser d’inattendu.

Combiné avec --diff, vous voyez même le contenu exact des changements prévus (utile surtout avec les modules template et copy, vus en section 5) :

ansible-playbook playbook_apache.yaml -i inventaire.yaml --check --diff

⚠️ Certains modules ne supportent pas complètement le mode --check (typiquement command et shell, puisqu’ils ne savent pas prédire l’effet d’une commande arbitraire sans l’exécuter). Ansible vous le signale généralement avec une ligne du type skipped, check mode not supported.

Ce qui casse l’idempotence (et comment l’éviter)

Trois pièges reviennent très souvent chez les débutants :

1. Utiliser command/shell sans discernement

# ❌ Pas idempotent : relance la commande à chaque exécution
- name: Créer un dossier
  ansible.builtin.command: mkdir /opt/nordika

# ✅ Idempotent : vérifie d'abord si le dossier existe
- name: Créer un dossier
  ansible.builtin.file:
    path: /opt/nordika
    state: directory

2. Oublier changed_when sur une commande brute nécessaire

Parfois, command ou shell restent le seul moyen de faire quelque chose (on l’a vu avec raw en 1.5). Dans ce cas, il faut préciser vous-même à Ansible quand considérer que quelque chose a changé :

- name: Vérifier une version installée
  ansible.builtin.command: myapp --version
  register: version_check
  changed_when: false  # une simple lecture ne "change" jamais rien

3. Des valeurs qui varient à chaque exécution

Un date ou un identifiant généré aléatoirement dans une tâche produira systématiquement changed, même si rien de significatif n’a changé sur la machine — parce que la valeur elle-même change à chaque fois. Ce genre de cas se détecte vite : le changed revient à chaque exécution, alors qu’aucune vraie modification n’a lieu.

Ce qu’il faut retenir

• L’idempotence, c’est rejouer le même playbook sans effet indésirable une fois l’état atteint.
• ok = rien à faire, changed = une action a été nécessaire — un playbook sain affiche ok partout à la deuxième exécution.
• --check (et --diff) permettent de vérifier ce qu’un playbook ferait, sans rien exécuter réellement.
• Les modules dédiés sont (presque) toujours idempotents par nature — command/shell ne le sont jamais par défaut.

Dans la prochaine leçon, on regarde les options d’exécution d’un playbook (-v, --check, --diff en détail) et comment lire correctement un résultat qui ne se passe pas comme prévu.