Introduction
Ansible recherche sa configuration selon un ordre prédéfini. Un fichier ansible.cfg au niveau du projet est essentiel, car il garantit la reproductibilité des commandes, quelle que soit la session shell utilisée.
Dans ce laboratoire, vous allez créer un petit projet, rédiger un fichier ansible.cfg, définir les paramètres par défaut de l'inventaire, ajouter des variables partagées et effectuer vos premières vérifications Ansible depuis le répertoire du projet.
Créer un projet minimal et un inventaire
Dans cette étape, vous allez créer les répertoires et le fichier d'inventaire nécessaires à la configuration d'Ansible au niveau du projet. Ce laboratoire partant d'une machine virtuelle vierge, vous ne créerez que les fichiers strictement nécessaires.
Créez la structure du projet.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,group_vars,playbooks}
Ce laboratoire maintient volontairement le projet à une taille réduite. inventory contiendra la liste des hôtes gérés, group_vars stockera les variables qu'Ansible charge automatiquement, et playbooks est réservé aux futurs fichiers d'automatisation.
Accédez au répertoire du projet.
cd rhce-ansible
Créez un inventaire contenant un hôte géré local.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF
Le nom d'hôte node1 est un alias d'inventaire, et non une machine virtuelle distincte. Le paramètre ansible_connection=local permet à Ansible d'exécuter des modules sur ce même système RHEL tout en vous permettant de vous exercer au ciblage par groupe.
Rédiger le fichier ansible.cfg pour le projet
Dans cette étape, vous allez créer le fichier ansible.cfg. La section [defaults] contrôle les comportements courants. Configurer inventory vous évite de devoir saisir -i inventory/hosts à chaque commande.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet afin que les chemins relatifs pointent vers le projet Ansible.
cd /home/labex/project/rhce-ansible
Rédigez le fichier de configuration.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
remote_user = labex
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
stdout_callback = default
EOF
Chaque paramètre élimine une option répétitive en ligne de commande. inventory pointe vers le fichier d'inventaire statique, remote_user définit l'utilisateur de connexion par défaut, host_key_checking = False évite les invites de confirmation de clé SSH dans les environnements de laboratoire, et interpreter_python = auto_silent permet à Ansible de sélectionner Python sans afficher d'avertissements de découverte inutiles.
Vérifiez quel fichier de configuration Ansible utilise.
ansible --version | sed -n '1,4p'
La sortie doit inclure config file = /home/labex/project/rhce-ansible/ansible.cfg.
C'est une habitude importante : si Ansible lit un fichier de configuration différent, les commandes ultérieures pourraient utiliser un inventaire, un callback ou un comportement de connexion différent de ce que prévoit le laboratoire.
Inspecter l'inventaire via les paramètres par défaut du projet
Dans cette étape, vous allez vérifier si ansible.cfg pointe correctement Ansible vers votre inventaire. Comme le chemin de l'inventaire est configuré, cette commande ne nécessite pas l'option -i.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet.
cd /home/labex/project/rhce-ansible
Affichez le graphe de l'inventaire.
ansible-inventory --graph
Le graphe doit afficher le groupe managed et l'hôte node1.
La vue graphique est utile avant d'exécuter des commandes, car elle montre l'inventaire tel qu'il a été analysé par Ansible. Si un groupe ou un hôte est absent ici, une cible de playbook ne le trouvera pas non plus.
Listez les variables d'hôte pour node1.
ansible-inventory --host node1
Vous devriez voir ansible_connection défini sur local.
La vue de l'hôte affiche les variables résolues, et non simplement la ligne brute de l'inventaire. Les laboratoires suivants utiliseront la même commande pour diagnostiquer si les variables proviennent de l'inventaire, de group_vars ou de host_vars.
Ajouter des variables partagées
Dans cette étape, vous allez ajouter des variables pour tous les hôtes gérés. Les fichiers situés dans group_vars sont chargés automatiquement lorsque leurs noms correspondent aux groupes d'inventaire ou à all.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet.
cd /home/labex/project/rhce-ansible
Créez group_vars/all.yml. Le format YAML utilise des paires clé: valeur. Veillez à laisser un espace après chaque deux-points.
cat > group_vars/all.yml <<'EOF'
project_owner: labex
baseline_message: Managed by the RHCE Ansible prep project
EOF
Le nom de fichier all.yml a une signification particulière : Ansible l'applique à chaque hôte de l'inventaire. Comme il s'agit de YAML, l'indentation et l'espace après chaque deux-points sont essentiels à la validité du fichier.
Utilisez le module debug pour afficher une variable depuis l'hôte géré.
ansible managed -m ansible.builtin.debug -a 'var=baseline_message'
La sortie doit inclure le message provenant de group_vars/all.yml.
La commande ad hoc se compose de trois parties : managed est le motif d'hôte, -m sélectionne le module, et -a transmet l'argument du module. Un résultat positif prouve que l'inventaire configuré et le chargement des variables fonctionnent correctement.
Exécuter une vérification de connectivité
Dans cette étape, vous allez exécuter le module ping. Il ne s'agit pas d'un ping ICMP, mais d'un module Ansible qui vérifie si Ansible peut exécuter Python sur l'hôte cible.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet.
cd /home/labex/project/rhce-ansible
Exécutez la vérification sur le groupe managed.
ansible managed -m ansible.builtin.ping
Un résultat réussi inclut pong.
Le module ping d'Ansible est un test d'exécution de module, et non un ping réseau ICMP. Il prouve qu'Ansible peut atteindre l'hôte, démarrer Python et renvoyer un résultat de module.
Enregistrez un petit fichier de preuve à l'aide d'une commande ad hoc. Le module copy écrit du contenu vers un chemin de destination.
ansible managed -m ansible.builtin.copy -a 'content=ansible_cfg_ready dest=/home/labex/project/rhce-ansible/config-check.txt mode=0644'
Lorsque cette commande indique changed, cela signifie qu'Ansible a créé ou mis à jour le fichier. Si vous l'exécutez à nouveau avec le même contenu et les mêmes permissions, le résultat devrait être ok, car l'état souhaité existe déjà.
Résumé
Vous avez créé un fichier ansible.cfg au niveau du projet, confirmé qu'Ansible charge bien l'inventaire configuré, ajouté des variables partagées et effectué des vérifications de modules ad hoc. Les laboratoires suivants s'appuieront sur cette configuration de projet reproductible.
