Basic setup¶
Objectif
Structurer un projet ansible avec un répertoire dédié, un fichier ansible.cfg local, un inventaire, la journalisation et l'élévation de privilèges.
Durée
~35 minutes
Voici le corrigé étape par étape pour réaliser l'ensemble des tâches demandées dans l'atelier. On part du principe que les VM sont démarrées (vagrant up) et que vous êtes connecté au Control Host (vagrant ssh control).
1. Préparation de l'environnement et de la communication SSH¶
Après avoir démarré les machines virtuelles avec la commande vagrant up, nous nous connectons au nœud de contrôle via vagrant ssh control.
La première étape consiste à modifier le fichier /etc/hosts du nœud de contrôle afin de pouvoir joindre les cibles par leur nom d'hôte (plutôt que par leur adresse IP). Pour cela, nous éditons le fichier :
Nous y ajoutons les lignes suivantes :
Ensuite, pour permettre à ansible de se connecter aux cibles sans intervention manuelle, nous générons une paire de clés SSH (sans mot de passe pour les besoins du lab) et nous la propageons sur les trois nœuds cibles pour l'utilisateur vagrant :
ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
ssh-copy-id vagrant@target01
ssh-copy-id vagrant@target02
ssh-copy-id vagrant@target03
2. Installation d'ansible et premier test¶
L'environnement étant basé sur Ubuntu 22.04, nous utilisons le gestionnaire de paquets apt pour installer ansible :
Pour valider que la communication fonctionne correctement, nous lançons un premier ping avec ansible. Afin de contourner l'absence d'inventaire à ce stade, nous passons les noms d'hôtes directement en argument, séparés par des virgules :
3. Structuration du projet ansible¶
L'une des bonnes pratiques avec ansible est de centraliser la configuration d'un projet dans un répertoire dédié. Nous créons donc un dossier monprojet :
À l'intérieur, nous créons un fichier de configuration vide :
Pour nous assurer qu'ansible prend bien en priorité ce fichier local plutôt que le fichier global du système (/etc/ansible/ansible.cfg), nous exécutons la commande suivante :
/home/vagrant/monprojet/ansible.cfg.
Nous configurons ensuite ce fichier pour y déclarer un fichier d'inventaire (nommé hosts) et pour activer la journalisation des actions d'ansible. Nous créons au préalable le répertoire destiné à accueillir les logs :
Contenu du fichier ansible.cfg :
Nous testons cette journalisation en lançant un ping sur localhost puis en consultant le fichier log :
4. Configuration de l'inventaire et élévation de privilèges¶
L'étape suivante consiste à créer le fichier d'inventaire hosts dans le répertoire du projet :
Nous y définissons un groupe [testlab] contenant nos trois cibles. Nous utilisons également le bloc de variables de groupe [testlab:vars] pour forcer l'utilisation de l'utilisateur vagrant et pour activer l'élévation de privilèges (ansible_become=yes), ce qui permet à ansible d'exécuter des commandes en tant que root (via sudo).
Contenu de l'inventaire hosts :
Grâce à cet inventaire, nous pouvons relancer un ping sur l'ensemble de l'infrastructure de manière beaucoup plus simple :
La capture d'écran suivante illustre ces opérations critiques :

L'image ci-dessus (image_1.png) montre deux choses :
1. Un ping réussi sur toutes les cibles (ansible all -m ping -> SUCCESS), validant la configuration de l'inventaire complet.
2. L'exécution réussie d'une commande ad-hoc privilégiée (ansible all -a "head -n 1 /etc/shadow") qui retourne l'état CHANGED et affiche les informations système, confirmant ainsi que le paramètre ansible_become=yes est bien pris en compte et fonctionne comme attendu.
5. Nettoyage de l'environnement¶
Une fois l'atelier terminé et les objectifs atteints, nous retournons sur la machine hôte pour détruire les machines virtuelles et libérer les ressources système :
Je retiens
ansible.cfgdans le répertoire du projet est prioritaire sur la configuration globale (/etc/ansible/ansible.cfg).log_pathpermet de tracer toutes les actionsansibledans un fichier de log.ansible_become=yesdans les variables d'inventaire active l'élévation de privilèges (sudo) pour tout le groupe.- L'inventaire INI supporte les groupes (
[testlab]) et les variables de groupe ([testlab:vars]).
Cheatsheet¶
| Symptôme | Cause probable | Correction |
|---|---|---|
ansible --version affiche config file = /etc/ansible/ansible.cfg au lieu du projet |
Le shell n'est pas dans le dossier du projet, ou ansible.cfg local est absent / en /g+w (refusé pour raisons de sécurité) |
cd ~/monprojet avant de lancer ansible ; vérifier que ansible.cfg existe et n'est pas group-writable |
ansible all -m ping → Missing sudo password |
ansible_become=yes actif mais l'utilisateur cible n'a pas NOPASSWD |
Ajouter --ask-become-pass au lancement ou s'assurer que l'utilisateur vagrant est bien sudoer sans mot de passe |
ansible -i hosts → « Unable to parse inventory » |
Inventaire INI mal formé (tabulation, groupe non fermé, section [testlab:vars] avant [testlab]) |
Valider le format : déclarer d'abord [testlab] puis [testlab:vars] ; pas de tabulation, uniquement des espaces |
cat ~/journal/ansible.log → vide ou erreur |
Dossier ~/journal non créé ou log_path mal orthographié |
mkdir -p ~/journal, vérifier log_path = ~/journal/ansible.log dans ansible.cfg |
head -n 1 /etc/shadow → Permission denied |
become: yes non actif ou mot de passe sudo manquant |
Vérifier [testlab:vars] ansible_become=yes et relancer |
Sources (principales)¶
- Docs
ansibleConfiguration file (ansible.cfg) - Docs
ansibleHow to build your inventory - Docs
ansibleansible-inventoryCLI (--list,--graph) - Docs
ansibleUnderstanding privilege escalation - Docs
ansibleGroup variables (group_vars) et host variables (host_vars) - Docs
ansibleVariables du comportement de connexion - Docs
ansiblebecome_user,become_method,become_flags
Précédent : Direnv Suite : Ad-hoc Commands