Ansible pour un seul serveur : une description qu'on exécute
Décrire l'état de la machine dans un playbook, l'exécuter jusqu'à changed=0, et savoir ce qu'une exécution verte prouve — et ne prouve pas.
Le cours de Bash s'achevait sur un script qu'on peut relancer. Ce cours est cette idée devenue un outil : un playbook affirme ce que la machine doit être, une exécution l'amène à être d'accord, et la deuxième exécution n'a rien à faire et le dit. Il gère un seul serveur — le vôtre, en SSH ou sur la boucle locale — et s'arrête là volontairement. La première moitié rend la machine descriptible : installation, inventaire, premier playbook. La seconde apprend à lire ce qu'une exécution rapporte, et où cette confiance s'arrête : les handlers, le récapitulatif champ par champ, et les secrets qu'un dépôt ne doit jamais contenir en clair.
Ce que vous saurez faire
- Dire ce qu'affirme un playbook et ce que prouve une exécution, et nommer les cas où un script reste la bonne réponse
- Installer ansible-core depuis les dépôts d'Ubuntu, écrire un inventaire d'une machine et tester la chaîne SSH et Python
- Écrire un playbook qui installe nginx, pose un fichier depuis un modèle et maintient une unité en marche, puis lire changed=0 pour ce qu'il veut dire
- Redémarrer un service seulement quand sa configuration a changé, par un handler plutôt que par une tâche
- Lire le récapitulatif champ par champ, et tenir le mot de passe du vault hors du dépôt qui contient le vault
Programme
- 01
Rendre la machine descriptible
Ce qu'Ansible promet, comment il atteint le serveur, et un premier playbook lu pour ce que veut dire changed=0.
- 02
Faire confiance à ce qu'une exécution rapporte
Des handlers qui ne redémarrent qu'au changement, le récapitulatif champ par champ, et des secrets tenus hors du dépôt.
Contenu technique vérifié le 18 septembre 2026