Introduction
L'automatisation n'est sûre que lorsqu'elle atteint les hôtes prévus. Deux alias pour une même machine, un hôte manquant ou une sélection trop large peuvent rendre une commande réussie trompeuse.
Dans ce labo, vous organiserez deux cibles SSH distinctes en groupes canary et stable, examinerez un groupe parent, prévisualiserez des motifs de sélection d'hôtes et créerez un fichier témoin uniquement sur le canary. Ansible et les connexions d'entraînement sont déjà préparés ; vous travaillerez sur l'inventaire et la portée des commandes.
Organiser les hôtes en groupes
Dans cette étape, vous regrouperez les deux hôtes SSH existants sans dupliquer leurs identités ni leurs adresses.
Ouvrez le Terminal et entrez dans le projet :
cd /home/labex/project
Lisez l'inventaire fourni avant de le modifier :
cat inventory.ini
Il définit web1 et web2 avec des valeurs ansible_host différentes. Conservez ces lignes et les paramètres de connexion [all:vars]. Les noms d'inventaire identifient les hôtes ; placer le même nom dans plusieurs groupes ne crée pas un autre serveur.
Un groupe décrit un ensemble d'hôtes. Nous utiliserons canary pour le premier hôte, stable pour le second et webservers comme parent contenant les deux groupes. Ajoutez ces sections. >> préserve le fichier existant, et le marqueur de document en ligne entre guillemets conserve le texte collé littéral :
cat >> inventory.ini <<'EOF'
[canary]
web1
[stable]
web2
[webservers:children]
canary
stable
EOF
[canary] et [stable] contiennent des noms d'hôte. Une section se terminant par :children contient des noms de groupe : webservers hérite donc des hôtes appartenant à canary et stable. N'ajoutez pas de nouvelles adresses de destination dans ces groupes.
ansible-inventory --graph dessine les appartenances résolues :
ansible-inventory --graph
Vous devez voir web1 sous canary et web2 sous stable, avec les deux groupes sous webservers. Les entrées spéciales all et ungrouped peuvent aussi apparaître. Un hôte peut apparaître dans plusieurs branches du graphe tout en restant un seul hôte d'inventaire.
Un motif d'hôtes sélectionne les cibles d'une commande. Prévisualisez le groupe parent sans exécuter de module :
ansible webservers --list-hosts
Vous devez obtenir exactement web1 et web2. Dans un motif, :& signifie l'intersection : sélectionner les hôtes appartenant aux deux parties. Placez-le entre guillemets pour que le shell n'interprète pas & :
ansible 'webservers:&canary' --list-hosts
Vous devez obtenir uniquement web1. Cette prévisualisation vous permet de détecter une erreur de sélection avant de modifier un hôte.
Limiter un changement au canary
Dans cette étape, vous effectuerez une petite modification sur le canary tout en préservant l'hôte stable et le contrôleur.
Le premier motif d'une commande sélectionne un ensemble initial. --limit le restreint davantage ; il n'ajoute aucun hôte extérieur à cet ensemble. Prévisualisez une sélection limitée avant de l'utiliser :
ansible webservers --limit canary --list-hosts
Vous devez obtenir un seul hôte, web1. Une limite ne correspondant à aucun hôte ne démontrerait pas une modification réussie, même si la commande se termine sans échec de module.
Utilisez le module command du labo précédent pour exécuter touch. Cette commande Linux crée un fichier vide s'il n'existe pas, et met à jour son horodatage s'il existe. Le fichier témoin doit être placé dans le répertoire personnel de l'utilisateur automation géré. La valeur -a entre guillemets garde l'exécutable et le chemin ensemble :
ansible webservers --limit canary -m ansible.builtin.command -a 'touch /home/automation/canary-ready'
Vous devez obtenir un résultat de commande réussi uniquement pour web1. Cette action est volontairement un simple exercice de portée ; touch peut actualiser les horodatages lors d'exécutions répétées, donc son statut CHANGED ne démontre pas l'idempotence.
Examinez les fichiers visibles dans le répertoire personnel de chaque utilisateur géré. ls énumère le répertoire sur chaque cible puisqu'il est exécuté par le module command d'Ansible :
ansible webservers -m ansible.builtin.command -a 'ls /home/automation'
Le résultat web1 doit contenir canary-ready. Le résultat web2 ne doit pas contenir ce nom ; sa sortie stdout peut être vide. Ce sont des répertoires distants, distincts de l'espace de travail du contrôleur.
Enfin, examinez le répertoire actuel du contrôleur :
ls
Il doit afficher la configuration et l'inventaire du projet, sans fichier témoin canary-ready local. Vous avez sélectionné un véritable hôte géré au lieu de modifier le contrôleur. Les prochains labos utiliseront des modules qui déclarent directement l'état des fichiers, puis vérifieront l'idempotence.
Résumé
Vous avez préservé deux identités d'inventaire distinctes, organisé les hôtes et les groupes enfants, prévisualisé un motif d'intersection entre guillemets et restreint une commande avec --limit. L'état réel des cibles a montré le fichier témoin uniquement sur le canary, tandis que l'hôte stable et le contrôleur restaient en dehors du changement.
