Introduction
Une commande Ansible ponctuelle peut inspecter un parc ou appliquer un petit état de configuration explicite. Choisir le bon module facilite la compréhension de son comportement et des résultats renvoyés.
Vous inspecterez deux cibles Linux, préparerez un répertoire géré et distribuerez un fichier source du contrôleur. Vous comparerez l'exécution de commandes à des modules qui indiquent si l'état demandé nécessitait réellement un changement. L'inventaire et les connexions SSH sont déjà préparés.
Inspecter un groupe d'hôtes avec des modules
Dans cette étape, vous choisirez des modules Ansible ponctuels pour inspecter les deux nœuds gérés préparés.
Ouvrez le Terminal et sélectionnez l'espace de travail :
cd /home/labex/project
Une commande ad hoc exécute directement un module sur des hôtes d'inventaire sélectionnés, sans playbook. Sa forme de base est ansible PATTERN -m MODULE -a ARGUMENTS. Le labo fournit un groupe webservers contenant les deux cibles SSH. Prévisualisez ce groupe :
ansible webservers --list-hosts
Vous devez obtenir exactement web1 et web2. Utilisez le module command du labo précédent pour exécuter uname -s, qui affiche le nom du noyau du système d'exploitation :
ansible webservers -m ansible.builtin.command -a 'uname -s'
Chaque hôte doit afficher Linux. Le module command indique normalement CHANGED même pour une consultation en lecture seule. Examinez stdout et le statut de retour plutôt que d'interpréter ce libellé comme un changement de configuration.
Le module setup collecte des faits, des informations structurées découvertes sur un nœud géré. L'argument filter du module restreint les faits renvoyés. Examinez le nom de la distribution :
ansible webservers -m ansible.builtin.setup -a 'filter=ansible_distribution'
Chaque résultat réussi doit inclure un objet ansible_facts contenant "ansible_distribution": "Ubuntu". setup indique habituellement changed: false pour cette inspection. Les faits décrivent la cible, et non votre contrôleur ; les prochains labos les utiliseront dans l'automatisation.
Un résultat de tâche non nul est un échec, et UNREACHABLE indique un problème de connexion. Deux hôtes attendus exigent deux résultats réussis. Ne confondez pas une sélection vide avec une inspection terminée.
Déclarer un répertoire géré
Dans cette étape, vous utiliserez un module orienté état pour préparer le même répertoire sur les deux cibles.
Le module file gère l'état du système de fichiers. Son path identifie le chemin cible, et state=directory demande un répertoire plutôt qu'un fichier vide. mode=0750 accorde tous les droits au propriétaire, la lecture et la traversée au groupe, et aucun accès aux autres. Le zéro initial indique une valeur de permissions octale.
Les tâches ordinaires s'exécutent sous le compte automation préparé. Créez un répertoire dans le répertoire personnel de cet utilisateur, ce qui ne nécessite aucun become :
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Les deux hôtes doivent indiquer changed: true lors de la première création du répertoire, avec un champ path ou dest identifiant /home/automation/ops. Le répertoire appartient à automation puisque ce compte le crée.
Exécutez de nouveau la même déclaration :
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Vous devez maintenant obtenir changed: false sur les deux hôtes : l'état demandé existe déjà. Cela diffère de l'émission répétée d'une commande générale telle que touch, qui peut encore actualiser les horodatages.
Copier un fichier du contrôleur sur les deux cibles
Dans cette étape, vous créerez un petit fichier source sur le contrôleur et déploierez son contenu exact avec des permissions cibles explicites.
printf écrit le texte et un saut de ligne final ; > crée ou remplace la source dans le projet actuel. Le format entre guillemets garde le message ensemble, tandis que \n demande le saut de ligne :
printf 'Managed by Ansible\n' > message.txt
Le module copy transfère une source du contrôleur vers une destination gérée. src se trouve sur le contrôleur, tandis que dest se trouve sur chaque cible. Pour un fichier ordinaire, mode=0640 accorde la lecture et l'écriture au propriétaire, la lecture au groupe et aucun accès aux autres :
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Chaque cible doit indiquer changed: true lors de la copie initiale. Répétez le même transfert :
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Vous devez obtenir changed: false lorsque les octets et les permissions demandées correspondent déjà. Le module file a préparé le répertoire parent ; copier un fichier ne remplace pas cette étape de création de répertoire.
Lisez le contenu distant réel avec le module command :
ansible webservers -m ansible.builtin.command -a 'cat /home/automation/ops/message.txt'
Les deux sorties stdout doivent afficher Managed by Ansible. La consultation par commande peut indiquer CHANGED, mais le résultat changed:false du module copy précédent décrit un fichier géré déjà conforme. Votre source du contrôleur reste distincte des deux copies distantes.
Résumé
Vous avez exécuté des modules ad hoc sur un véritable groupe à deux hôtes, interprété les sorties de commandes et découvert les faits de distribution. Vous avez déclaré un répertoire, copié une source distincte du contrôleur avec des permissions explicites et observé des résultats inchangés lorsque les modules orientés état trouvaient un état conforme lors d'une nouvelle exécution.
