Introduction
Vous préparez un nœud de contrôle Ansible pour gérer deux serveurs Linux. Avant d'écrire des automatisations, vous avez besoin d'une installation prévisible et de la preuve que le contrôleur peut exécuter des modules Python sur les deux cibles.
Dans ce labo, vous créerez un environnement virtuel de projet, installerez Ansible Core depuis un cache de paquets hors ligne, l'activerez dans le Terminal et utiliserez un inventaire fourni pour tester deux véritables connexions SSH. Des connaissances élémentaires de la ligne de commande suffisent ; aucune expérience préalable d'Ansible n'est nécessaire.
Créer un environnement de contrôle isolé
Dans cette étape, vous créerez l'environnement Python qui accueillera votre propre installation d'Ansible.
Ansible s'exécute sur un nœud de contrôle et se connecte aux nœuds gérés par SSH. Votre Terminal LabEx est le nœud de contrôle Ubuntu. Deux conteneurs Linux préparés, web1 et web2, servent de nœuds gérés distincts : ils possèdent des adresses, des noms d'hôte et des systèmes de fichiers différents, mais partagent le noyau de la VM. Vous n'aurez besoin ni de commandes Docker ni de modifier les paramètres de connexion de la plateforme.
Un environnement virtuel Python sépare les paquets du projet de ceux du système d'exploitation et des outils partagés du cours. L'image contient déjà une commande Ansible partagée pour l'infrastructure, mais votre tâche consiste à installer une copie distincte dans /home/labex/project/.venv.
Ouvrez le Terminal. Utilisez cd pour sélectionner le répertoire du projet ; les chemins relatifs suivants seront résolus à partir de ce répertoire :
cd /home/labex/project
pwd affiche votre répertoire de travail actuel :
pwd
La sortie doit être /home/labex/project. Continuez à utiliser ce répertoire pendant tout le labo.
ansible-python sélectionne le Python préparé pour le cours. --version affiche sa version :
ansible-python --version
Vous devez obtenir Python 3.12.15. Le Python système du nœud de contrôle reste distinct ; ne le remplacez pas.
L'option -m venv exécute le module d'environnement virtuel de Python. Le dernier argument, .venv, nomme le répertoire à créer dans le projet. Le point initial le masque dans les listes ordinaires de répertoires :
ansible-python -m venv .venv
Cette commande se termine normalement sans sortie. Elle crée l'environnement et pip, le gestionnaire de paquets de Python ; Ansible n'est pas encore installé.
Exécutez le Python du nouvel environnement avec son chemin relatif. Cela confirme que vous pouvez utiliser l'interpréteur isolé sans l'activer au préalable :
.venv/bin/python --version
Cette commande doit aussi afficher Python 3.12.15. Les deux commandes Python utilisent la même version de Python, mais les paquets installés dans .venv appartiennent à ce projet.
Installer et activer Ansible hors ligne
Dans cette étape, vous installerez la version figée d'Ansible Core dans .venv et configurerez le Terminal pour l'utiliser.
Ansible Core fournit la commande ansible et les modules intégrés utilisés dans ce cours. Les fichiers wheel préparés sont des paquets Python locaux : l'installation ne dépend donc pas de téléchargements sur Internet. Le fichier des dépendances indique des versions compatibles et figées.
La commande suivante utilise le Python du projet pour exécuter pip. install installe les paquets, --no-index désactive les index de paquets en ligne, --find-links sélectionne le répertoire local des fichiers wheel et -r lit le fichier des dépendances :
.venv/bin/python -m pip install --no-index --find-links /opt/labex/ansible-course/wheels -r /opt/labex/ansible-course/requirements.txt
La sortie énumère les paquets traités depuis le cache local et se termine par Successfully installed ..., avec notamment ansible-core-2.21.5. Une nouvelle installation peut afficher à la place Requirement already satisfied.
L'activation place le répertoire des commandes de l'environnement en tête du chemin de recherche de ce shell. source exécute le script d'activation dans le Terminal actuel afin que le changement persiste pour les commandes suivantes :
source .venv/bin/activate
L'invite peut maintenant commencer par (.venv). Le Terminal utilise zsh ; rehash actualise les emplacements des commandes mis en cache après l'installation de nouveaux exécutables :
rehash
command -v indique quel exécutable est sélectionné par un nom de commande :
command -v ansible
Vous devez obtenir /home/labex/project/.venv/bin/ansible. Un chemin partagé tel que /usr/local/bin/ansible ne prouve pas que l'installation du projet est active. Si vous ouvrez un nouveau Terminal, revenez dans le projet, activez de nouveau l'environnement et exécutez rehash.
Inspectez maintenant la version d'Ansible exécutée :
ansible --version
Recherchez ces champs dans la sortie :
ansible [core 2.21.5]
config file = /home/labex/project/ansible.cfg
...
ansible python module location = /home/labex/project/.venv/lib/python3.12/site-packages/ansible
executable location = /home/labex/project/.venv/bin/ansible
python version = 3.12.15 ...
...
Les chemins de l'exécutable et du module montrent que vous utilisez l'installation du projet. Le fichier de configuration est fourni par le labo ; vous apprendrez à le configurer dans le prochain groupe de compétences.
Enfin, la commande check de pip vérifie la compatibilité des dépendances des paquets installés :
.venv/bin/python -m pip check
Vous devez obtenir No broken requirements found. Vous disposez maintenant d'un contrôleur fonctionnel sans avoir modifié les paquets système ni la chaîne d'outils partagée.
Se connecter aux deux nœuds gérés
Dans cette étape, vous examinerez l'inventaire préparé et exécuterez un test de connexion fondé sur Python sur les deux cibles SSH.
Un inventaire indique à Ansible les hôtes qu'il peut gérer. cat affiche le contenu d'un fichier ; lisez l'inventaire fourni pour le projet :
cat inventory.ini
Il présente la structure suivante :
web1 ansible_host=...
web2 ansible_host=...
[all:vars]
ansible_user=automation
ansible_ssh_private_key_file=/home/labex/.local/share/ansible-course/id_ed25519
ansible_python_interpreter=/usr/bin/python3
Les adresses réelles remplacent ... ; utilisez les valeurs existantes. web1 et web2 sont des noms d'inventaire, tandis que ansible_host donne chaque destination SSH. [all:vars] applique les paramètres de connexion suivants aux deux hôtes. automation est le compte ordinaire à l'intérieur des nœuds gérés, et non votre compte labex sur le nœud de contrôle. Le labo fournit une nouvelle clé d'entraînement et des clés d'hôte approuvées ; vous n'avez pas à générer de clés ni à modifier les paramètres SSH.
Le chemin Python cible /usr/bin/python3 appartient à chaque nœud géré. Il diffère du Python du projet sur le contrôleur : la plupart des modules Ansible nécessitent Python aussi bien sur la cible que sur le contrôleur.
Le fichier ansible.cfg fourni sélectionne cet inventaire lorsque les commandes s'exécutent depuis le projet. all sélectionne tous les hôtes de l'inventaire ; --list-hosts permet de prévisualiser cette sélection sans exécuter de module :
ansible all --list-hosts
Vous devez obtenir exactement ces deux noms d'hôte ; leur ordre peut varier :
hosts (2):
web1
web2
L'option -m sélectionne un module, une unité de travail Ansible. ansible.builtin.ping est le nom pleinement qualifié du module ping intégré. Il se connecte par SSH et exécute Python sur chaque cible ; ce n'est pas un ping réseau ICMP :
ansible all -m ansible.builtin.ping
Les deux hôtes doivent renvoyer des résultats contenant ces champs stables ; l'ordre des résultats peut varier :
web1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
web2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
Un pong prouve que l'authentification SSH et l'exécution du Python cible ont fonctionné pour cet hôte. changed: false signifie que ce test de connexion n'a demandé aucun changement de configuration. Un seul hôte en réussite ne suffit pas : recherchez les deux noms. UNREACHABLE signifie que la connexion a échoué ; FAILED indique l'échec d'une tâche. Une liste d'hôtes vide ne démontre pas non plus la connectivité.
Si la commande échoue, vérifiez d'abord que vous êtes toujours dans le répertoire du projet, que command -v ansible sélectionne .venv/bin/ansible et que l'inventaire fourni contient toujours les deux destinations d'origine. Ne modifiez pas la configuration de connexion, SSH et sudo de la plateforme.
Résumé
Vous avez créé un environnement de contrôle isolé, installé des versions figées des paquets Ansible Core depuis un cache hors ligne, activé les commandes du projet et vérifié leurs chemins et leurs dépendances. Vous avez lu l'inventaire fourni et reçu un pong Python de chaque nœud distinct géré par SSH. Vous savez maintenant distinguer le Python du contrôleur, le Python des cibles et les noms d'inventaire avant d'aborder la configuration du projet.
