GUIDE TECHNIQUE · ANSIBLE
Créer et tester un inventaire Ansible
Créer un inventaire Ansible INI réellement utilisable, expliquer les groupes et les variables de connexion, puis exécuter un ping Ansible sur la machine locale. Une connexion distante SSH nécessite des prérequis différents.
L’ESSENTIEL EN BREF
Comment procéder ?
Créer un inventaire Ansible INI réellement utilisable, expliquer les groupes et les variables de connexion, puis exécuter un ping Ansible sur la machine locale. Une connexion distante SSH nécessite des prérequis différents.
Résultat à atteindre : ansible-inventory --graph montre lab et localhost.
Avant de commencer : Installer ansible-core dans un environnement Python isolé ; vérifier ansible --version.
01 · CADRAGE
Ce que vous allez mettre en place
Créer un inventaire Ansible INI réellement utilisable, expliquer les groupes et les variables de connexion, puis exécuter un ping Ansible sur la machine locale. Une connexion distante SSH nécessite des prérequis différents.
Pour qui : Administrateurs, ingénieurs DevOps, SRE et équipes de recette
ansible-core récent installé sur un poste Linux/macOS ou environnement Python. Démonstration locale sans SSH, serveur ni élévation de privilège.
Vérifiez la compatibilité avec votre environnement réel. Les versions ne sont jamais présumées identiques d’un tenant à l’autre.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Installer ansible-core dans un environnement Python isolé ; vérifier ansible --version.
- Écrire inventory.ini dans un dossier de recette dédié, avec accès au Python local.
- Ne pas mettre de mots de passe ni de clés privées dans l'inventaire ; pour des hôtes distants, gérer SSH et known_hosts.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Chaque étape explique l’action, sa raison, le contrôle attendu et les erreurs habituelles. Adaptez les exemples aux paramètres de votre propre environnement.
ÉTAPE 1 / 5
Préparer les machines de recette
Un environnement Ansible local permet de vérifier la mécanique d'inventaire sans intervenir sur une machine cliente.
- Créer un dossier dédié et relever la version installée.
- Confirmer qu'Ansible trouve un interpréteur Python.
- Définir explicitement un seul hôte local de recette.
mkdir -p ansible-inventory-lab && cd ansible-inventory-lab
ansible --version
python3 --versionÀ vérifier : Ansible et Python affichent une version, dans un dossier de recette.
Point de vigilance ADN : Si Ansible n'est pas installé, utiliser une installation documentée dans un venv ; ne pas modifier un Python système en production.
ÉTAPE 2 / 5
Créer inventory.ini avec un alias local
Le nom de groupe lab sera utilisé dans les commandes ; ansible_connection=local évite toute tentative SSH.
- Créer inventory.ini avec un groupe [lab].
- Définir localhost comme cible et la connexion locale.
- Pour de vrais serveurs, remplacer la connexion locale par un accès SSH autorisé.
cat > inventory.ini <<'EOF'
[lab]
localhost ansible_connection=local
EOFÀ vérifier : inventory.ini contient exactement un hôte dans le groupe lab.
Point de vigilance ADN : En production, ranger les variables hôte/groupe dans les emplacements group_vars et host_vars appropriés.
ÉTAPE 3 / 5
Examiner l'inventaire interprété
ansible-inventory résout les groupes, hôtes et variables avant toute connexion.
- Lister le contenu effectif de l'inventaire.
- Vérifier le groupement et l'absence de doublons.
- Comparer les host vars déclarées aux variables résolues.
ansible-inventory -i inventory.ini --list
ansible-inventory -i inventory.ini --graphÀ vérifier : Le groupe lab possède localhost, et la variable ansible_connection est local.
Point de vigilance ADN : Un groupe vide ou un nom non reconnu entraîne un comportement différent de la cible voulue.
ÉTAPE 4 / 5
Vérifier la connexion avec ping
Le module ping Ansible contrôle la connexion et l'exécution Python ; ce n'est pas le protocole ICMP.
- Limiter l'exécution au groupe lab.
- Exécuter le module ansible.builtin.ping.
- Relire la réponse SUCCESS et l'état de l'hôte.
ansible -i inventory.ini lab -m ansible.builtin.pingÀ vérifier : localhost | SUCCESS et une réponse pong apparaissent.
Point de vigilance ADN : Pour un parc distant, ce test échoue sans SSH, Python distant et autorisations adaptés, même si le ping réseau répond.
ÉTAPE 5 / 5
Documenter les limites d'accès
Il faut prouver que le périmètre choisi ne concerne pas un groupe supplémentaire.
- Lister seulement les hôtes effectivement ciblés.
- Supprimer les fichiers de recette sans toucher à un inventaire réel.
- Documenter les paramètres SSH/privileges nécessaires avant un déploiement.
ansible -i inventory.ini lab --list-hosts
# Nettoyage facultatif : rm inventory.iniÀ vérifier : Une seule cible locale est listée ; aucune ressource distante n'a été modifiée.
Point de vigilance ADN : Ne jamais désactiver la vérification des clés d'hôte pour contourner un échec de connexion.
SOURCES ET FIABILITÉ
Statut de validation du guide
Rédaction : ADN Consulting. Statut : procédure documentée, exécution en laboratoire non attestée.
Les exemples et versions indiqués doivent être vérifiés sur un environnement autorisé. Aucune validation individuelle par un consultant n’est revendiquée sans preuve.
05 · RECETTE
Comment vérifier que tout fonctionne ?
ansible-inventory --graph montre lab et localhost.
ansible.builtin.ping retourne SUCCESS/pong sur localhost.
Les variables de connexion sont explicites et aucune donnée sensible n'est dans inventory.ini.
Le jeu de recette ne touche aucun hôte distant.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
Échec de syntaxe
Cause probable : Format du fichier ou option incompatible
Que faire : Vérifier indentation YAML, version et documentation officielle.
Accès refusé
Cause probable : Droits ou contexte de connexion incorrects
Que faire : Contrôler l'utilisateur, le namespace et les permissions.
État non conforme
Cause probable : Configuration non appliquée ou ressource différente
Que faire : Relire les sorties détaillées, événements et paramètres effectifs.
Le conseil de l’expert ADN
Avant de généraliser cette configuration, validez-la sur un périmètre représentatif, documentez les critères de réussite et conservez une procédure de retour arrière. Une automatisation fiable se juge sur l’état final observé, les permissions maîtrisées et un retour arrière testé.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Puis-je lancer cet exemple directement en production ?
Non : les valeurs et droits sont illustratifs. Une recette, une revue de sécurité et une procédure de retour arrière sont nécessaires.
Le succès de la commande suffit-il ?
Non, il faut observer le résultat attendu sur la ressource ou le service ciblé.
AUTRES TECHNOLOGIES
Guides complémentaires
Ce tutoriel s’inscrit dans une chaîne technique plus large. Retrouvez les méthodes associées aux technologies voisines.