Introduction
Ansible peut être installé correctement tout en utilisant le mauvais inventaire, interpréteur ou niveau de privilèges. Un projet fiable rend ces choix explicites et confirme leur effet sur des cibles réelles.
Dans ce labo, vous créerez une configuration de projet, examinerez les valeurs chargées, définirez le Python cible dans l'inventaire et comparerez l'exécution ordinaire à l'élévation explicite des privilèges sur deux nœuds SSH préparés. Cet environnement indépendant fournit Ansible et les connexions ; aucune installation de paquets ni modification des serveurs SSH n'est nécessaire.
Créer et charger la configuration du projet
Dans cette étape, vous créerez une configuration de projet et confirmerez qu'Ansible la charge réellement.
Vous avez déjà installé Ansible dans le labo précédent. Cet environnement indépendant fournit l'installation partagée du cours afin de vous concentrer sur la configuration. Ouvrez le Terminal et sélectionnez l'espace de travail :
cd /home/labex/project
Ansible utilise un seul fichier de configuration : il choisit le premier disponible parmi ANSIBLE_CONFIG, ansible.cfg dans le répertoire actuel, la configuration du répertoire personnel de l'utilisateur et la configuration système. Changer de répertoire peut donc changer la configuration de projet chargée. Une variable d'environnement peut sélectionner un autre fichier même lorsqu'un fichier de projet existe.
Le fichier préparé connection-reference.cfg contient les paramètres de connexion d'entraînement d'origine. cat l'affiche :
cat connection-reference.cfg
Il sélectionne l'inventaire du projet et un fichier de clés d'hôte approuvées. Le labo a déjà créé les clés et les nœuds ; ne modifiez pas votre connexion à la plateforme ni le serveur SSH.
Créez le fichier ansible.cfg ci-dessous. cat > écrit l'entrée standard dans un fichier en remplaçant son contenu existant. <<'EOF' commence un document en ligne : collez toutes les lignes jusqu'au dernier EOF inclus. Les guillemets autour du marqueur conservent le texte littéral. Les noms de sections INI entre crochets regroupent les paramètres, et chaque ligne name = value définit une option.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory sélectionne la liste d'hôtes. host_key_checking conserve la vérification de l'identité des serveurs. interpreter_python définit le Python cible par défaut, et non l'interpréteur du contrôleur. become = False maintient les tâches ordinaires sans privilèges élevés. Les ssh_args préparés utilisent le fichier known_hosts d'entraînement, exigent des clés approuvées et réutilisent brièvement les connexions SSH.
Affichez les informations de version et de configuration :
ansible --version
Recherchez config file = /home/labex/project/ansible.cfg. Le chemin du module appartient à l'installation partagée du cours dans ce labo ; votre exercice d'installation précédent utilisait un environnement apprenant distinct.
ansible-config dump affiche la configuration effective. --only-changed la limite aux paramètres différents des valeurs par défaut et indique leur origine :
ansible-config dump --only-changed
Recherchez CONFIG_FILE() = /home/labex/project/ansible.cfg, un DEFAULT_HOST_LIST du projet et INTERPRETER_PYTHON défini sur /usr/bin/python3. La sortie utilise des noms d'options internes qui peuvent différer de l'orthographe INI. Lire un fichier ne prouve pas à lui seul qu'Ansible l'a chargé.
Testez la configuration du projet avec le module ping Python que vous connaissez déjà :
ansible all -m ansible.builtin.ping
web1 et web2 doivent tous deux renvoyer pong. Exécutez les commandes dans cet espace de travail pour que la configuration voulue reste active.
Définir l'interpréteur cible dans l'inventaire
Dans cette étape, vous définirez une variable de connexion pour les deux hôtes et comprendrez sa relation avec la valeur par défaut du projet.
Lisez l'inventaire préparé :
cat inventory.ini
Il contient deux destinations ansible_host distinctes, suivies de [all:vars]. Les paramètres après cette section s'appliquent aux deux hôtes, notamment ansible_user=automation et le chemin de la clé privée d'entraînement. Ils décrivent le compte SSH et l'authentification sur les nœuds gérés.
Une variable de connexion nommée ansible_python_interpreter remplace la valeur par défaut de configuration interpreter_python pour ses hôtes. Utilisez-la lorsqu'un inventaire nécessite un interpréteur cible particulier. Une valeur par défaut correcte ne peut pas compenser une variable d'inventaire qui pointe vers un exécutable absent.
printf affiche du texte ; \n représente un saut de ligne. >> ajoute du contenu sans remplacer l'inventaire existant. Ajoutez la variable d'interpréteur sous la section [all:vars] existante :
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
Affichez de nouveau l'inventaire et repérez le nouveau paramètre sous [all:vars] :
cat inventory.ini
L'installation Python du contrôleur reste inchangée. Ce chemin sera exécuté séparément à l'intérieur de chaque nœud géré. Testez les deux cibles :
ansible all -m ansible.builtin.ping
Chacune doit toujours renvoyer pong et changed: false. Vous disposez maintenant d'un paramètre d'interpréteur fonctionnel propre à l'inventaire, ainsi que d'une valeur par défaut du projet. La sortie de configuration décrit les valeurs par défaut ; les variables de connexion peuvent les remplacer pendant l'exécution.
Comparer l'exécution ordinaire et avec privilèges élevés
Dans cette étape, vous observerez l'utilisateur distant réel avant et après une élévation explicite des privilèges.
Le module command exécute un programme sur la cible. -a fournit les arguments du module ; placez id -un entre guillemets pour que le shell transmette le programme et son option sous forme d'une seule chaîne d'arguments. id -un affiche le nom de l'utilisateur effectif :
ansible all -m ansible.builtin.command -a 'id -un'
Les deux hôtes doivent indiquer automation. Il s'agit du compte des nœuds gérés sélectionné par l'inventaire, et non de l'utilisateur labex du contrôleur.
--become demande l'élévation des privilèges pour cette invocation. Les nœuds d'entraînement autorisent le compte automation à utiliser sudo sans mot de passe ; la valeur par défaut du projet maintient toutefois l'élévation désactivée pour les exécutions ordinaires :
ansible all -m ansible.builtin.command -a 'id -un' --become
Les deux hôtes doivent indiquer root. Le module command d'Ansible indique normalement CHANGED lorsqu'il exécute une commande, même pour cette consultation d'identité en lecture seule. Ce libellé ne prouve pas à lui seul une modification de configuration système ; interprétez la sortie stdout et le statut de retour réels.
Répétez sans --become :
ansible all -m ansible.builtin.command -a 'id -un'
La sortie revient à automation. L'élévation était explicite pour une invocation et ne constituait pas un changement permanent de compte de connexion. Laissez l'élévation globale désactivée et conservez la configuration des comptes de la plateforme.
Résumé
Vous avez créé et chargé une configuration de projet, examiné les valeurs par défaut effectives et fourni un interpréteur cible de priorité supérieure dans l'inventaire. L'exécution réelle de modules par SSH a confirmé les deux cibles, et les consultations d'identité ont montré la différence entre l'accès ordinaire automation et un become explicite. Ces vérifications constituent une base pour diagnostiquer les paramètres de connexion sans modifier l'accès à la plateforme.
