Le serveur réparé à la main
À deux heures du matin, l’affiche d’une boutique dit Ouvert alors qu’elle devrait dire Fermé. Quelqu’un a modifié le fichier sur le serveur en production sans prévenir personne.
Quand le playbook repasse, il devrait le remarquer et remettre le fichier en ordre. Cette leçon montre comment, et comment regarder d’abord sans rien changer.
À la fin de cette leçon
Remarque
Je peux lancer un playbook deux fois et dire ce qui a changé et pourquoi.
Mots-clés
| Mot | Ce que ça veut dire | Exemple |
|---|---|---|
| Idempotent | le relancer ne change plus rien | |
| Dérive | le réel ne correspond plus à sa description | |
| Mode check | une exécution qui signale les changements sans les faire | --check |
| Diff | les lignes qui changeraient | --diff |
| Récapitulatif | les totaux affichés à la fin d’une exécution | PLAY RECAP |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Un playbook décrit l’arrivée, pas les gestes
Une tâche dit comment un fichier doit être, pas quoi taper. Si le fichier est déjà bon, la tâche ne fait rien et signale ok. Sinon, elle le corrige et signale changed.
Un bon playbook est donc idempotent : la deuxième exécution ne signale aucun changement.
Créer un dossier et y entrer
mkdir -p ~/atelier-iac/derive && cd ~/atelier-iac/deriveAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Écrire un playbook d’une tâche
printf '%s\n' '- hosts: localhost' ' connection: local' ' gather_facts: false' ' vars:' ' horaires: "Ouvert de 9 h à 17 h"' ' tasks:' ' - name: ecrire l affiche' ' ansible.builtin.copy:' ' dest: ./affiche.txt' ' content: "{{ horaires }}\n"' ' mode: "0644"' > site.ymlAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Le lancer une première fois
ansible-playbook -i localhost, site.yml | grep -E "changed="Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Le relancer
ansible-playbook -i localhost, site.yml | grep -E "changed="Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
La dérive est un changement non noté
La dérive, c’est quand le réel cesse de correspondre à la description, souvent parce que quelqu’un l’a modifié à la main. L’idempotence rend la dérive facile à réparer.
Lancez d’abord le playbook en mode check. Il signale ce qu’il changerait, --diff montre les lignes, mais rien n’est écrit.
Modifier le fichier à la main
echo "Ferme toute la semaine" > affiche.txt; cat affiche.txtAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Regarder d’abord avec check et diff
ansible-playbook -i localhost, site.yml --check --diff | grep -E "^[-+][^-+]|changed="Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Relire le fichier
cat affiche.txtAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Le lancer, puis encore une fois
ansible-playbook -i localhost, site.yml | grep -E "changed="; cat affiche.txt; ansible-playbook -i localhost, site.yml | grep -E "changed="Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Une tâche shell ne voit pas le changement
Le module copy compare le fichier avec le souhait. Le module shell lance seulement une commande : il ne peut pas savoir si quelque chose a changé. Il signale changed à chaque fois.
Le lab Ansible refuse un playbook fait seulement de commandes shell pour cette raison.
Écrire le même travail en commande shell
printf '%s\n' '- hosts: localhost' ' connection: local' ' gather_facts: false' ' tasks:' ' - name: ecrire avec un shell' ' ansible.builtin.shell: echo "Ouvert de 9 h a 17 h" > ./shell.txt' > shell.ymlAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Le lancer deux fois
ansible-playbook -i localhost, shell.yml | grep -E "changed="; ansible-playbook -i localhost, shell.yml | grep -E "changed="Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Erreur fréquente
Attention
Beaucoup pensent que changed=0 à la première exécution veut dire que le playbook n’a rien fait d’utile. Cela veut dire que la machine correspondait déjà au souhait. Une exécution qui dit toujours changed cache la dérive, car un vrai changement ressemble à un changement ordinaire.
OpenTofu trouve la dérive en rafraîchissant l’état
Avec un vrai provider, tofu plan demande d’abord au vrai service ce qui existe, et montre l’écart avec l’état. C’est ainsi qu’il remarque une modification à la main.
terraform_data du lab garde une valeur et rien en dehors d’OpenTofu : il n’y a rien à modifier à la main. Cette leçon utilise donc un fichier.
Une convergence calculée en Python
# Amener une machine au souhait et compter ce qui a changé.
souhait = {"horaires": "Ouvert de 9 h à 17 h", "telephone": "0100"}
machine = {"horaires": "Fermé", "autre": "gardez-moi"}
changes = 0
for nom in souhait:
if nom not in machine or machine[nom] != souhait[nom]:
machine[nom] = souhait[nom]
changes = changes + 1
print("changes =", changes)
# Relancez la boucle, puis regardez changes.
Pour aller plus loin : changer le souhait
Lancez ansible-playbook -i localhost, site.yml -e '{"horaires": "Ouvert de 10 h à 16 h"}' | grep -E "changed=" puis cat affiche.txt. Lancez la même commande une seconde fois.
Pourquoi la première exécution change-t-elle le fichier et pas la seconde, et quelle variable a gagné ?