Trente ordinateurs, une seule recette
Un playbook Ansible est un fichier qui décrit comment une machine doit être réglée, puis la règle à l’identique chaque fois. Tu l’écris une fois et tu l’appliques sur une machine ou sur mille.
Le lycée doit préparer trente ordinateurs pour la rentrée. À la main, on oublie une étape sur deux ou trois d’entre eux. Un script ne l’oublie jamais.
À la fin de cette leçon
Remarque
Je peux lire un playbook et dire ce qu’il va changer sur une machine.
Mots clés
| Mot | Ce que ça veut dire | Exemple |
|---|---|---|
| Ansible | un outil qui règle une machine d’après un fichier | |
| Playbook | le fichier qui liste ce que la machine doit devenir | site.yml |
| Tâche | une étape du playbook, un seul travail | |
| Module | un petit programme qui sait faire un seul travail | |
| Variable | un nom qui garde une valeur qu’on peut changer | site_name |
| Idempotent | qui ne change plus rien quand on le refait |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Un script refait la même installation à l’identique
À la main, chaque machine reçoit un peu de fatigue et d’oubli. Deux ordinateurs censés être pareils ne le sont plus au bout d’un mois.
On écrit donc la liste des étapes dans un fichier. Un outil comme Ansible lit le fichier et règle la machine. Le fichier devient la mémoire du réglage.
Exemple : trois ordinateurs installés à la main
| Étape | Ordinateur 1 | Ordinateur 2 | Ordinateur 3 |
|---|---|---|---|
| Installer le navigateur | fait | fait | fait |
| Installer l’éditeur de code | fait | oublié | fait |
| Copier le fichier d’accueil | fait | fait | ancienne version |
| Résultat | conforme | incomplet | différent |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Un playbook est une liste de tâches
Un playbook est écrit en YAML, un texte où les retraits montrent qui appartient à qui. Chaque tâche a un nom et appelle un module.
Un module est un petit programme qui fait un seul travail : installer un paquet, copier un fichier, créer un dossier. Voici un exemple, qui n’est pas celui du lab.
Un playbook d’exemple, ligne par ligne
| Ligne du playbook | Ce qu’elle dit |
|---|---|
| `- name: Préparer la salle` | Le nom du playbook |
| `hosts: all` | Sur quelles machines agir |
| `become: true` | Demande les droits d’administrateur |
| `- name: Le paquet cowsay est installé` | Une tâche, avec son nom |
| `ansible.builtin.package:` | Le module que la tâche appelle |
| `name: cowsay` | Le paquet visé |
| `state: present` | Le résultat voulu : installé |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Lire le playbook ligne à ligne
Les retraits, les espaces au début d’une ligne, montrent qui appartient à qui : la tâche est dans le playbook, le module dans la tâche.
state: present dit ce que tu veux obtenir, pas comment y arriver. Tu décris le résultat voulu. Le module décide s’il faut agir ou non.
Regarde le projet du lab
ls -l ansible-labAffiché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.
Lis le playbook du lab
cat ansible-lab/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.
Ce que contient le projet du lab
Dans le dossier, site.yml est le playbook et inventory.ini dit quelles machines Ansible gère : ici, seulement celle-ci. ansible.cfg garde ses réglages, et templates contient un fichier avec un blanc à remplir.
Le playbook n’a qu’une tâche, qui affiche un message. Il a aussi une variable, site_name, qui vaut Riverside College, et trois lignes TODO pour les travaux du lab.
Un bon playbook est idempotent
Lance un playbook deux fois de suite. La première fois, il change la machine. La seconde, la machine est déjà comme voulu : il ne doit rien changer.
On dit que le playbook est idempotent. Le récapitulatif de fin le montre : changed=0 veut dire que rien n’a changé.
Lance le playbook du lab
ansible-playbook -i ansible-lab/inventory.ini ansible-lab/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.
Lire le récapitulatif de fin
La dernière ligne dit ok=2 et changed=0. Deux tâches se sont bien passées et aucune n’a rien modifié, car afficher un message ne change rien.
Ansible a aussi posé une question à la machine avant d’agir. C’est toujours ainsi : regarder d’abord, changer seulement si besoin.
Exemple : deux passages du même playbook
| Passage | Le paquet est là ? | Ce que fait Ansible | Récapitulatif |
|---|---|---|---|
| 1 | non | installe le paquet | changed=1 |
| 2 | oui | ne fait rien | changed=0 |
| 3 | oui | ne fait rien | changed=0 |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Pose une question au module stat
ansible localhost -i ansible-lab/inventory.ini -m ansible.builtin.stat -a path=/etc/ansible-labAffiché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.
Ce que répond le module stat
Le module stat regarde un fichier ou un dossier. Pour /etc/ansible-lab, il répond "exists": false et "changed": false.
Le dossier n’existe pas encore : c’est l’un des travaux du lab. Le module a regardé et n’a rien touché.
Une erreur fréquente
Attention
Beaucoup pensent qu’un playbook est une suite de commandes à rejouer. Une commande brute refait son travail à chaque passage. Utilise plutôt un module : il regarde l’état de la machine et n’agit que s’il faut.
Pour aller plus loin : un passage de trop
Dans ton devoir, une étape commande change toujours quelque chose. Ajoute une étape commande à ton plan et lance est_idempotent.
Que renvoie-t-il ? Quelle étape faudrait-il remplacer par un module pour que le plan redevienne idempotent ?