Ansible : installation et prise en main

Configurer un serveur à la main, puis le suivant, puis le suivant, en espérant avoir fait exactement les mêmes commandes à chaque fois — c’est la définition même du travail qui finit par vous exploser au visage un vendredi soir. Ansible automatise ce travail de façon reproductible, sans rien installer sur les machines gérées. Ce tutoriel couvre l’installation, l’inventaire, les commandes ad-hoc, l’écriture de playbooks et les roles.

Le principe : agentless, en SSH, idempotent

Contrairement à des outils comme Puppet ou Chef qui nécessitent d’installer un agent sur chaque machine gérée, Ansible fonctionne en mode agentless : il se connecte simplement en SSH (ou WinRM pour Windows) depuis un « nœud de contrôle » vers les machines cibles, exécute des modules Python temporaires, puis nettoie derrière lui. Rien à installer ni à maintenir sur les serveurs gérés, à part un client SSH et Python — déjà présents sur l’immense majorité des systèmes Linux.

Deuxième principe fondamental : l’idempotence. Un playbook Ansible bien écrit peut être exécuté cent fois de suite sans effet de bord : s’il constate qu’un paquet est déjà installé ou qu’un fichier a déjà le bon contenu, il ne fait rien et le signale comme tel (« ok », pas « changed »). C’est ce qui permet de rejouer sereinement une configuration sans craindre de casser quelque chose qui fonctionne déjà.

Installation

Plusieurs méthodes officielles existent ; pipx est aujourd’hui la méthode recommandée par la documentation Ansible pour installer l’outil dans un environnement isolé, sans polluer le Python système :

# Avec pipx (recommandé)
sudo apt install pipx        # ou : python3 -m pip install --user pipx
pipx ensurepath
pipx install --include-deps ansible

# Alternative : gestionnaire de paquets de la distribution
sudo apt install ansible     # Debian/Ubuntu
sudo dnf install ansible     # Fedora/RHEL

# Vérification
ansible --version

Notez la distinction entre ansible-core (le moteur minimal) et le paquet ansible complet, qui embarque en plus une large collection de modules communautaires — le paquet complet est le plus simple pour démarrer.

Préparer l’accès SSH

1. Générez une paire de clés SSH dédiée si vous n’en avez pas déjà une : ssh-keygen -t ed25519.
2. Copiez la clé publique sur chaque machine à gérer : ssh-copy-id utilisateur@serveur.
3. Vérifiez que vous pouvez vous connecter sans mot de passe avant d’aller plus loin — Ansible dépend entièrement de cet accès SSH fonctionnel.

L’inventaire : déclarer vos machines

L’inventaire liste les machines gérées, organisées en groupes. Format INI simple (inventory.ini) :

[web]
web01.example.local
web02.example.local

[db]
db01.example.local

[production:children]
web
db

Un format YAML équivalent est également possible et souvent préféré dans les projets plus structurés. Pour des infrastructures dynamiques (cloud, conteneurs), Ansible propose des inventaires dynamiques qui interrogent une API (AWS, Proxmox, etc.) au lieu d’un fichier statique.

Commandes ad-hoc : tester avant d’automatiser

Avant d’écrire un playbook complet, une commande ad-hoc permet de vérifier rapidement une action ponctuelle :

# Tester la connectivité
ansible all -i inventory.ini -m ping

# Exécuter une commande shell sur un groupe
ansible web -i inventory.ini -m command -a "uptime"

# Installer un paquet (nécessite les droits élevés)
ansible web -i inventory.ini -m apt -a "name=curl state=present" --become

Le module ping ne fait pas un ping réseau classique : il vérifie que Python est disponible sur la cible et que la connexion SSH + les identifiants fonctionnent — un premier test indispensable après toute nouvelle installation.

Écrire un premier playbook

Un playbook est un fichier YAML qui décrit un état désiré, exécuté dans l’ordre, tâche par tâche :

---
- name: Installer et démarrer Nginx
  hosts: web
  become: true
  tasks:
    - name: Installer le paquet nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Démarrer et activer le service
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

    - name: Déployer la page d'accueil
      ansible.builtin.template:
        src: templates/index.html.j2
        dest: /var/www/html/index.html
      notify: Recharger Nginx

  handlers:
    - name: Recharger Nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Exécution : ansible-playbook -i inventory.ini site.yml. Relancez-le une seconde fois : les tâches déjà satisfaites remontent en ok plutôt qu’en changed — c’est l’idempotence en action, la preuve que le playbook ne casse rien à la relance.

Le handler illustre un autre concept clé : une action déclenchée uniquement si une tâche précédente a réellement changé quelque chose (ici, recharger Nginx seulement si la page a été modifiée), plutôt que de la relancer systématiquement à chaque exécution.

Organiser en roles

Dès qu’un playbook grossit, les roles permettent de découper la configuration en blocs réutilisables (un role « nginx », un role « postgresql », un role « durcissement-securite »…) :

ansible-galaxy init roles/nginx

Cette commande génère l’arborescence standard (tasks/, handlers/, templates/, defaults/, vars/…) que vous remplissez ensuite, puis référencez depuis un playbook :

---
- name: Configurer les serveurs web
  hosts: web
  become: true
  roles:
    - nginx

Protéger les secrets avec ansible-vault

Un mot de passe de base de données ou une clé API n’a rien à faire en clair dans un playbook versionné sur Git. ansible-vault chiffre le contenu sensible :

# Créer un fichier chiffré
ansible-vault create group_vars/db/vault.yml

# Éditer un fichier existant
ansible-vault edit group_vars/db/vault.yml

# Exécuter un playbook qui référence des variables chiffrées
ansible-playbook site.yml --ask-vault-pass

Bonnes pratiques

• Versionnez vos playbooks dans Git, mais jamais le mot de passe vault en clair — utilisez un fichier de mot de passe hors dépôt ou un gestionnaire de secrets externe.
• Testez d’abord en mode --check (simulation à blanc) sur un environnement non critique avant d’exécuter un nouveau playbook en production.
• Utilisez des tags (--tags) pour n’exécuter qu’une partie ciblée d’un long playbook pendant le développement, sans tout rejouer.
• Documentez vos roles (README, valeurs par défaut commentées dans defaults/main.yml) — un role sans documentation redevient une boîte noire dès que quelqu’un d’autre (ou vous, six mois plus tard) doit le réutiliser.

Une fois cette base maîtrisée en ligne de commande, l’étape naturelle suivante pour une équipe est de piloter ces mêmes playbooks depuis une interface web centralisée avec RBAC, planification et journalisation — c’est exactement le rôle d’AWX, couvert dans le tutoriel suivant.