Installation et configuration

Ansible ne nécessite d'installation que sur le nœud de contrôle. Les machines cibles n'ont besoin que d'un accès SSH et de Python 3. Cette section couvre l'installation, la configuration de base, et la vérification de la connectivité.

Prérequis

• Nœud de contrôle : Linux ou macOS, Python 3.10+, pip, SSH client (ansible-core 2.18+ exige Python 3.10 minimum sur le nœud de contrôle)
• Machines cibles : SSH actif, Python 3 installé (la plupart des distributions l'incluent par défaut)
• Authentification : clé SSH recommandée, mot de passe possible via --ask-pass

Installation via pip

L'installation via pip est recommandée pour obtenir une version récente, indépendamment de la version packagée par la distribution :

pip3 install --user ansible
# Vérifier l'installation
ansible --version

Sur Debian 13 Trixie, le paquet ansible disponible via apt est souvent en retard d'une version majeure. Pip garantit l'accès aux dernières collections.

Pour un environnement isolé (recommandé en production) :

python3 -m venv ~/.venv/ansible
source ~/.venv/ansible/bin/activate
pip install ansible ansible-lint

ansible.cfg : configuration du comportement

Ansible cherche sa configuration dans cet ordre : variable d'environnement ANSIBLE_CONFIG, puis ./ansible.cfg (répertoire courant), puis ~/.ansible.cfg, puis /etc/ansible/ansible.cfg.

Un fichier ansible.cfg minimal par projet :

[defaults]
inventory = inventory/
remote_user = debian
private_key_file = ~/.ssh/id_ed25519
host_key_checking = False   # uniquement en développement
forks = 10
stdout_callback = yaml

[ssh_connection]
pipelining = True

host_key_checking = False désactive la vérification du fingerprint SSH. Acceptable en lab, à proscrire en production.

Premier inventaire statique

L'inventaire décrit les machines cibles. Format INI minimal :

[web]
web01.example.com
web02.example.com ansible_user=ubuntu

[db]
db01.example.com ansible_port=2222

[prod:children]
web
db

Le groupe prod contient ici tous les hôtes de web et db. Deux groupes spéciaux existent toujours : all (tous les hôtes) et ungrouped (hôtes sans groupe).

Pour placer l'inventaire dans un dossier (recommandé) :

mkdir -p inventory/
# inventory/hosts.ini contient le contenu ci-dessus

Vérification de la connectivité

Le module ping Ansible n'est pas un ping ICMP : il établit une connexion SSH, vérifie Python, et retourne pong :

# Tous les hôtes
ansible all -m ping

# Un groupe spécifique
ansible web -m ping

# Un hôte spécifique
ansible web01.example.com -m ping -v

Commandes ad-hoc

Les commandes ad-hoc permettent d'exécuter un module unique sans playbook :

# Uptime sur tous les serveurs
ansible all -m command -a "uptime"

# Installer un paquet (avec élévation sudo)
ansible web -m apt -a "name=nginx state=present" --become

# Copier un fichier
ansible db -m copy -a "src=/tmp/test.conf dest=/etc/test.conf" --become

# Récupérer des facts
ansible web01.example.com -m setup | grep ansible_distribution

Les commandes ad-hoc sont utiles pour des opérations ponctuelles ou de la vérification rapide. Dès qu'une opération doit être reproductible, elle mérite un playbook.

Structure de projet recommandée

Avant d'aller plus loin, voici la structure minimale d'un projet Ansible propre :

mon-projet/
├── ansible.cfg
├── inventory/
│   └── hosts.ini
├── group_vars/
│   └── all.yml
├── host_vars/
├── roles/
└── playbooks/
    └── site.yml