Cinq serveurs, cinq réglages différents
Une petite entreprise a cinq serveurs web. Des personnes différentes les ont réglés à la main pendant deux ans. L’un d’eux répond lentement et personne ne sait pourquoi.
Le remède : écrire le réglage dans un fichier, et laisser un outil mettre chaque machine d’accord avec lui. Si un serveur tombe, on en refait un identique en quelques minutes.
À la fin de cette leçon
Remarque
Je peux écrire un playbook qui règle une machine et ne change plus rien à la deuxième exécution.
Mots-clés
| Mot | Ce que ça veut dire | Exemple |
|---|---|---|
| Playbook | un fichier qui liste comment les machines doivent être réglées | |
| Tâche | une étape d’un playbook | |
| Module | un outil fourni que la tâche utilise | ansible.builtin.file |
| Inventaire | la liste des machines à gérer | |
| Idempotent | sans risque à relancer, car la deuxième exécution ne change rien | |
| Modèle | un fichier à trous que des variables remplissent |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Un playbook dit comment la machine doit être
Un playbook ne dit pas "crée un dossier". Il dit "ce dossier doit exister".
L’outil regarde la machine, voit ce qui est déjà bon et ne corrige que ce qui est faux. Vous décrivez l’état final. L’outil trouve les étapes.
Cette VM contient un dossier de projet. Entrez-y et lisez les fichiers. Les commandes partagent un terminal : le déplacement reste.
Entrer dans le dossier du projet
cd ~/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.
Lire le playbook
cat 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 l’inventaire
cat inventory.iniAffiché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.
Lancé deux fois, il ne change plus rien
Une tâche idempotente peut tourner autant de fois qu’on veut avec le même résultat. La première fois, elle travaille. La deuxième, elle ne trouve rien à faire.
Essayez. La commande suivante écrit votre propre petit playbook, exercice.yml. Il crée un dossier et une note dans /tmp. Il reste à côté de site.yml et ne le touche pas.
Écrire votre playbook d’essai
printf '%s\n' '- hosts: localhost' ' gather_facts: false' ' vars:' ' equipe: Comptabilite' ' tasks:' ' - name: Creer le dossier de notes' ' ansible.builtin.file:' ' path: /tmp/carnet-demo' ' state: directory' ' - name: Ecrire une note' ' ansible.builtin.copy:' ' dest: /tmp/carnet-demo/note.txt' ' content: "Bonjour {{ equipe }}"' > exercice.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 exercice.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 relancer
ansible-playbook exercice.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.
Une erreur fréquente
Attention
On croit souvent qu’un playbook est un script shell écrit en YAML. Un script refait chaque étape à chaque fois. Un module de playbook vérifie d’abord et n’agit que s’il le faut. N’utilisez le module shell que s’il n’existe aucun autre module : il signale un changement à chaque exécution.
Un modèle remplit ses trous avec des variables
Un modèle est un fichier avec des trous, comme {{ nom_du_site }}. Une variable remplit chaque trou quand le fichier est créé.
Changez la variable et le fichier change, sans modification à la main. On peut fixer une variable sur la ligne de commande avec -e.
Lisez d’abord le modèle du labo. Puis changez l’équipe dans votre playbook.
Lire le modèle du labo
cat templates/welcome.txt.j2Affiché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 avec une autre équipe
ansible-playbook exercice.yml -e equipe=SupportAffiché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.
Essai à blanc : que reviendrait-il ?
ansible-playbook exercice.yml --check --diffAffiché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 la note
cat /tmp/carnet-demo/note.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.
Pour aller plus loin
Écrivez un second playbook, shell.yml, avec une seule tâche qui utilise ansible.builtin.shell pour lancer date > /tmp/carnet-demo/horodatage.txt. Lancez-le deux fois et lisez le bilan à chaque fois.
Ajoutez ensuite sous la tâche args: avec creates: /tmp/carnet-demo/horodatage.txt, puis relancez-le deux fois. Expliquez ce qui a changé dans le bilan, et pourquoi.