Skip to content

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 :

sudo nano /etc/hosts

Nous y ajoutons les lignes suivantes :

192.168.56.20 target01
192.168.56.30 target02
192.168.56.40 target03

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 :

sudo apt update
sudo apt install -y 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 :

ansible all -i target01,target02,target03 -m ping

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 :

mkdir -pv ~/monprojet
cd ~/monprojet

À l'intérieur, nous créons un fichier de configuration vide :

touch ansible.cfg

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 :

ansible --version | head -n 2
Le résultat confirme que le paramètre "config file" pointe bien vers /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 :

mkdir -pv ~/journal
nano ansible.cfg

Contenu du fichier ansible.cfg :

[defaults]
inventory = ./hosts
log_path = ~/journal/ansible.log

Nous testons cette journalisation en lançant un ping sur localhost puis en consultant le fichier log :

ansible localhost -m ping
cat ~/journal/ansible.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 :

nano hosts

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 :

[testlab]
target01
target02
target03

[testlab:vars]
ansible_user=vagrant
ansible_become=yes

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 :

Validation de l'inventaire complet et de l'élévation de privilèges

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 :

exit
vagrant destroy -f

Je retiens

  • ansible.cfg dans le répertoire du projet est prioritaire sur la configuration globale (/etc/ansible/ansible.cfg).
  • log_path permet de tracer toutes les actions ansible dans un fichier de log.
  • ansible_become=yes dans 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 pingMissing 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/shadowPermission denied become: yes non actif ou mot de passe sudo manquant Vérifier [testlab:vars] ansible_become=yes et relancer

Sources (principales)


Précédent : Direnv Suite : Ad-hoc Commands