# Revue d’un playbook Ansible avant de l’appliquer à un parc de serveurs de production

> Un playbook Ansible qui fonctionne en test peut casser un parc en production. Liste de contrôle avant de lancer un run sur des serveurs déjà en service.

- Auteur : WordPress Développement
- Publié le : 2022-06-19
- Mis à jour le : 2022-06-19
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/revue-playbook-ansible-avant-production/

## L’essentiel

- vérifier l'idempotence sur un run répété, pas seulement le premier
- limiter le blast radius avec un lot restreint et --limit
- toujours prévoir un chemin de retour arrière documenté

`ansible-playbook site.yml --check --diff` : cette commande devrait être le tout premier réflexe avant chaque exécution sur un parc en production, et elle est pourtant souvent sautée par excès de confiance quand le playbook « a déjà tourné hier sans problème ».

Cette liste de contrôle rassemble les points vérifiés avant d'appliquer un playbook Ansible à un parc de serveurs WordPress mutualisés en production, indépendamment de son contenu métier. Elle ne traite pas de la rédaction du playbook lui-même, mais de la revue qui précède son exécution réelle sur des machines qui servent déjà du trafic.

## Vérifier l'idempotence, pas seulement le résultat du premier passage

Un playbook qui produit le bon résultat au premier passage peut très bien casser quelque chose au second. C'est le piège classique des tâches qui modifient un fichier de configuration par ajout de ligne sans vérifier sa présence au préalable, ou qui redémarrent un service à chaque exécution au lieu de ne le faire qu'en cas de changement effectif.

- Chaque tâche `lineinfile` ou `blockinfile` a-t-elle un marqueur ou une regexp suffisamment précise pour ne pas dupliquer son contenu à chaque run ?
- Les handlers de redémarrage de service sont-ils bien déclenchés par `notify`, et non exécutés systématiquement en tâche directe ?
- Le playbook a-t-il été rejoué deux fois de suite sur un environnement de test, avec vérification qu'aucune tâche ne remonte « changed » au second passage ?

## Limiter le rayon d'impact avant le premier déploiement réel

Même un playbook validé en test mérite d'être appliqué d'abord sur un lot restreint de serveurs en production, jamais sur l'ensemble du parc en une seule commande. L'option `--limit`, combinée à un groupe d'inventaire dédié aux serveurs « canari », permet de vérifier le comportement réel sur un sous-ensemble représentatif avant généralisation.

```
ansible-playbook site.yml \
  --limit "canari_hebergement" \
  --check --diff

# après validation du dry-run
ansible-playbook site.yml \
  --limit "canari_hebergement"
```

Sur le parc concerné par cette revue, le choix a été fait de ne jamais dépasser cinq serveurs par lot de déploiement, même pour un playbook jugé mineur. Ce plafond, arbitraire au départ, s'est révélé pertinent lors d'un incident où une tâche de mise à jour de paquet avait un effet de bord non anticipé sur une version de noyau particulière : seuls cinq serveurs ont été affectés avant l'arrêt du déploiement.

> L'essentiel à retenir : vérifier l'idempotence sur un run répété, pas seulement le premier ; limiter le blast radius avec un lot restreint et --limit ; toujours prévoir un chemin de retour arrière documenté

## Vérifier le comportement en cas d'échec partiel

Un playbook peut échouer au milieu de son exécution sur un serveur donné, sans que les suivants du même lot soient concernés. La revue doit donc vérifier ce qui se passe concrètement dans ce cas : le playbook s'arrête-t-il proprement, ou laisse-t-il le serveur concerné dans un état intermédiaire, avec certains services redémarrés et d'autres non ?

Les options `any_errors_fatal` et `max_fail_percentage` méritent d'être examinées explicitement plutôt que laissées à leur valeur par défaut. Sur un déploiement critique, fixer `max_fail_percentage: 0` garantit qu'un seul échec stoppe le lot entier, évitant qu'une majorité de serveurs se retrouve dans une configuration cible pendant qu'une minorité reste bloquée dans un état intermédiaire non documenté.

### Le chemin de retour arrière doit exister avant le lancement

Trop de playbooks sont revus pour leur contenu, jamais pour leur réversibilité. Avant chaque exécution en production, la question posée systématiquement est simple : si ce playbook produit un résultat indésirable, quelle commande ou quel playbook permet de revenir à l'état précédent, et a-t-elle été testée elle aussi ?

- Une sauvegarde des fichiers de configuration modifiés est-elle prise automatiquement avant écrasement, via un module comme `copy` avec `backup: yes` ou équivalent ?
- Existe-t-il un tag ou une version antérieure du playbook, versionnée dans le dépôt Git, permettant de rejouer l'état précédent en cas de besoin ?

## Vérifier les secrets et les variables sensibles

Un dernier point de contrôle, souvent négligé : les variables chiffrées avec `ansible-vault` sont-elles bien référencées et à jour pour l'environnement ciblé ? Un mot de passe de base de données obsolète dans un `group_vars` chiffré peut casser silencieusement une tâche de configuration sans message d'erreur explicite si le playbook ne vérifie pas le résultat de la connexion.

> Un playbook qui ne demande jamais de confirmation avant de toucher à la production n'est pas un playbook fiable, c'est un playbook qui n'a pas encore causé d'incident.

## En résumé

La revue d'un playbook Ansible avant application en production ne porte pas sur la qualité du code YAML seul, mais sur trois questions concrètes : que se passe-t-il si on le rejoue deux fois, que se passe-t-il si une partie du lot échoue, et comment revenir en arrière si le résultat n'est pas celui attendu. Ces trois questions, posées systématiquement avant chaque exécution sur le parc, ont évité plusieurs incidents qui seraient sinon passés inaperçus jusqu'au run suivant.