Introduction
Plusieurs commandes ponctuelles liées sont plus faciles à répéter et à examiner lorsqu'elles sont enregistrées dans un playbook. Un playbook utile décrit un état souhaité stable et produit des résultats observables sur chaque cible prévue.
Vous écrirez un petit playbook YAML avec les modules file et copy, l'appliquerez à deux nœuds SSH et vérifierez les fichiers créés ainsi qu'une nouvelle exécution sans changement. Ce labo présente les plays, les tâches et l'idempotence sans variables, boucles ni rôles.
Écrire un playbook en YAML
Dans cette étape, vous réunirez les modules file et copy déjà pratiqués dans un playbook réutilisable.
Entrez dans le projet dans le Terminal :
cd /home/labex/project
Un playbook est une liste YAML de plays. Chaque play associe un motif d'hôtes à une liste ordonnée de tâches. Chaque tâche nomme un module et ses arguments. Les libellés name aident à lire la sortie ; ils ne créent aucune configuration par eux-mêmes.
YAML utilise l'indentation pour imbriquer les données. Utilisez des espaces, pas des tabulations. Un - initial commence un élément de liste, et les deux-points introduisent la valeur d'une clé. Ici, tasks contient deux tâches de module. Les modes entre guillemets tels que "0750" restent des chaînes de permissions. gather_facts: false désactive la collecte automatique de faits car ces tâches à état fixe ne consomment pas de faits.
Créez le fichier avec un document en ligne entre guillemets, comme précédemment. Copiez jusqu'à la dernière ligne EOF incluse :
cat > workspace.yml <<'EOF'
- name: Prepare managed workspaces
hosts: all
gather_facts: false
tasks:
- name: Create the workspace directory
ansible.builtin.file:
path: /home/automation/workspace
state: directory
mode: "0750"
- name: Write the workspace notice
ansible.builtin.copy:
dest: /home/automation/workspace/README.txt
content: "Workspace managed by Ansible\n"
mode: "0640"
EOF
La première tâche déclare un répertoire. La seconde utilise l'argument content de copy pour fournir directement du texte littéral au lieu de lire un fichier src du contrôleur. La chaîne YAML entre guillemets doubles interprète \n comme un saut de ligne final. Un contenu fixe stabilise les exécutions répétées ; n'ajoutez pas d'horodatage variable.
Le play utilise hosts: all, soit les deux nœuds SSH fournis. Les tâches ordinaires s'exécutent sous automation ; leur répertoire personnel est donc accessible en écriture sans become.
ansible-playbook exécute les fichiers de playbook. Utilisez d'abord --syntax-check pour valider la structure sans appliquer les tâches :
ansible-playbook workspace.yml --syntax-check
Vous devez obtenir une ligne identifiant le playbook et aucune erreur d'analyse. La seule validation de syntaxe ne démontre ni la connectivité distante ni la conformité des fichiers finaux.
Prévisualisez la sélection d'hôtes du play avec --list-hosts :
ansible-playbook workspace.yml --list-hosts
Le play doit énumérer web1 et web2. Une liste vide ne constitue pas un playbook utilisable à deux hôtes.
Appliquer l'état souhaité
Dans cette étape, vous exécuterez le playbook et examinerez ses résultats distants réels.
Exécutez le fichier depuis le projet pour que sa configuration et son inventaire soient sélectionnés :
ansible-playbook workspace.yml
Ansible affiche le nom de chaque play et tâche, puis un PLAY RECAP. Dans un environnement neuf, les deux tâches doivent modifier chaque hôte :
web1 : ok=2 changed=2 unreachable=0 failed=0 ...
web2 : ok=2 changed=2 unreachable=0 failed=0 ...
L'espacement et l'ordre des hôtes peuvent varier. ok compte les tâches réussies, changed les tâches ayant nécessité des changements, et unreachable/failed doivent tous deux être à zéro. Le nom d'une tâche réussie ne prouve pas à lui seul les octets ou permissions requis du fichier.
Lisez chaque avis distant avec le module command ad hoc :
ansible all -m ansible.builtin.command -a 'cat /home/automation/workspace/README.txt'
Les deux valeurs stdout doivent afficher Workspace managed by Ansible. La consultation en lecture seule peut tout de même indiquer CHANGED ; les résultats file/copy du playbook décrivent l'état déclaré. Le répertoire géré a le mode 0750, l'avis le mode 0640, et tous deux appartiennent à automation.
Vérifier la convergence idempotente
Dans cette étape, vous répéterez le playbook et confirmerez qu'un état conforme ne nécessite aucun changement supplémentaire.
L'idempotence signifie qu'appliquer plusieurs fois le même état souhaité ne produit pas de changements inutiles après convergence. Exécutez de nouveau le même playbook :
ansible-playbook workspace.yml
Vous devez obtenir un récapitulatif pour chaque cible avec ok=2, changed=0, unreachable=0 et failed=0. Les deux fichiers restent présents et corrects. Un horodatage variable ou une commande générale inconditionnelle compromettrait ce résultat stable.
--check demande une prévisualisation : les modules compatibles prédisent les changements sans les appliquer. file et copy prennent tous deux en charge ce fonctionnement. Prévisualisez le playbook convergé :
ansible-playbook workspace.yml --check
Vous devez de nouveau obtenir zéro changement pour les deux hôtes. Une prévisualisation ne remplace ni la première exécution réelle ni l'inspection de l'état réel. Ici, elle confirme que les espaces de travail déjà créés correspondent aux déclarations.
Conservez le playbook pour le réutiliser. Ne masquez pas les changements avec changed_when et ne forcez pas des tâches à sortir du mode check pour fabriquer un récapitulatif propre ; le résultat doit refléter un état réellement conforme.
Résumé
Vous avez exprimé une sélection d'hôtes et des tâches de module ordonnées en YAML, vérifié la syntaxe et la portée cible, puis appliqué le playbook à deux véritables nœuds gérés. L'état réel des fichiers correspondait aux exigences, une deuxième exécution réelle n'a effectué aucun changement supplémentaire et le mode check en lecture seule n'a trouvé aucun changement en attente.
