Ansible : automatiser la gestion de serveurs Linux avec des playbooks

Introduction : l’automatisation de l’infrastructure comme levier de fiabilité

Administrer un parc de serveurs Linux à la main, c’est s’exposer à l’erreur humaine, aux dérivations de configuration et aux nuits blanchies lors des mises à jour de production. Chaque intervention manuelle introduit un risque : une option oubliée ici, un fichier de configuration légèrement différent là, et c’est tout un environnement qui se retrouve dans un état incohérent. L’automatisation n’est plus un luxe réservé aux grandes équipes DevOps : c’est aujourd’hui une nécessité pour tout administrateur qui gère plus de deux ou trois serveurs.

Ansible s’est imposé comme l’outil de gestion de configuration et d’automatisation de référence dans l’écosystème Linux. Sa philosophie est séduisante : pas d’agent à installer sur les machines cibles, une communication via SSH standard, et une syntaxe YAML lisible par un humain. Avec la sortie d’ansible-core 2.20.5 en avril 2026 et du paquet communautaire Ansible 13.6.0, l’outil continue de s’enrichir tout en conservant une compatibilité éprouvée avec Debian, Ubuntu, RHEL et leurs dérivés.

Dans cet article, nous allons explorer Ansible de façon concrète : installation, configuration d’un inventaire, écriture des premiers playbooks, utilisation des modules essentiels et mise en place d’une structure de projet maintenable. Les exemples sont directement applicables sur un environnement Debian/Ubuntu.

Qu’est-ce qu’Ansible et comment fonctionne-t-il ?

Ansible est un outil agentless : il n’y a rien à installer sur les serveurs cibles. Le nœud de contrôle (votre machine ou un serveur dédié) se connecte via SSH, pousse des modules Python temporaires sur les hôtes distants, les exécute, puis les supprime. Ce fonctionnement en mode push garantit une empreinte minimale sur les systèmes gérés.

L’architecture d’Ansible repose sur trois composants principaux :

• L’inventaire : la liste des hôtes à gérer, organisée en groupes.
• Les playbooks : des fichiers YAML décrivant l’état désiré de l’infrastructure.
• Les modules : des unités fonctionnelles encapsulant une action précise (installer un paquet, copier un fichier, redémarrer un service).

L’un des principes fondamentaux d’Ansible est l’idempotence : exécuter un playbook une fois ou dix fois doit produire le même résultat. Si le paquet est déjà installé, Ansible ne l’installe pas de nouveau. Si le fichier est déjà en place et identique, il n’est pas recopié. Ce comportement est essentiel pour une automatisation fiable et prévisible.

Installation d’Ansible sur Debian/Ubuntu

L’installation se fait en quelques commandes sur le nœud de contrôle :

# Mise à jour des dépôts et installation des prérequis
sudo apt update && sudo apt install -y software-properties-common

# Ajout du dépôt officiel Ansible (Ubuntu/Debian)
sudo add-apt-repository --yes --update ppa:ansible/ansible

# Installation d'ansible-core
sudo apt install -y ansible

# Vérification de la version installée
ansible --version

Sur des environnements où pip est préféré (virtualenv, CI/CD) :

pip install ansible
ansible --version
# ansible [core 2.20.5]

Configurer l’inventaire et la connexion SSH

L’inventaire est le point de départ de tout projet Ansible. Il recense les hôtes à gérer et les organise en groupes logiques. Voici un inventaire YAML — format recommandé en 2026 pour sa lisibilité :

# /etc/ansible/hosts  ou  inventaire/hosts.yaml
all:
  children:
    webservers:
      hosts:
        web01:
          ansible_host: 192.168.1.10
        web02:
          ansible_host: 192.168.1.11
    dbservers:
      hosts:
        db01:
          ansible_host: 192.168.1.20
  vars:
    ansible_user: admin
    ansible_ssh_private_key_file: ~/.ssh/id_ed25519
    ansible_python_interpreter: /usr/bin/python3

Avant d’aller plus loin, assurez-vous que la connexion SSH par clé publique est configurée sur tous les hôtes cibles. Testez la connectivité avec le module ping :

# Test de connectivité sur tous les hôtes
ansible all -i inventaire/hosts.yaml -m ping

# Test sur un groupe spécifique
ansible webservers -i inventaire/hosts.yaml -m ping

Une réponse "pong" de chaque hôte confirme que l’inventaire et la connexion SSH fonctionnent correctement.

Écrire son premier playbook

Un playbook est un fichier YAML composé d’une ou plusieurs plays. Chaque play cible un groupe d’hôtes et liste les tâches à exécuter séquentiellement. Voici un playbook de base qui installe et configure un serveur web Nginx :

# playbooks/nginx.yaml
---
- name: Installation et configuration de Nginx
  hosts: webservers
  become: true   # élévation de privilèges (sudo)

  tasks:

    - name: Mise à jour du cache apt
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Installation de Nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Déploiement de la configuration personnalisée
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'
      notify: Redémarrer Nginx

    - name: Activation et démarrage du service Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Redémarrer Nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Pour exécuter ce playbook :

# Vérification syntaxique avant exécution
ansible-playbook -i inventaire/hosts.yaml playbooks/nginx.yaml --syntax-check

# Simulation (dry-run) sans modification
ansible-playbook -i inventaire/hosts.yaml playbooks/nginx.yaml --check

# Exécution réelle
ansible-playbook -i inventaire/hosts.yaml playbooks/nginx.yaml

# Exécution avec verbosité pour débogage
ansible-playbook -i inventaire/hosts.yaml playbooks/nginx.yaml -v

Les modules essentiels à connaître

Ansible dispose de plus de 3 000 modules. Voici les indispensables pour la gestion quotidienne de serveurs Linux :

Gestion des paquets

- name: Installer plusieurs paquets
  ansible.builtin.apt:
    name:
      - curl
      - vim
      - git
      - htop
    state: present
    update_cache: true

- name: Mettre à jour tous les paquets
  ansible.builtin.apt:
    upgrade: dist
    update_cache: true

Gestion des fichiers et templates

- name: Copier un fichier statique
  ansible.builtin.copy:
    src: files/sshd_config
    dest: /etc/ssh/sshd_config
    owner: root
    mode: '0600'
    backup: true

- name: Créer un répertoire
  ansible.builtin.file:
    path: /var/log/myapp
    state: directory
    owner: www-data
    group: www-data
    mode: '0755'

- name: Déployer un template Jinja2
  ansible.builtin.template:
    src: templates/app.conf.j2
    dest: /etc/myapp/app.conf

Gestion des utilisateurs

- name: Créer un utilisateur système
  ansible.builtin.user:
    name: deployer
    groups: sudo
    shell: /bin/bash
    create_home: true
    state: present

- name: Ajouter une clé SSH autorisée
  ansible.posix.authorized_key:
    user: deployer
    state: present
    key: "{{ lookup('file', 'files/deployer.pub') }}"

Exécution de commandes

- name: Exécuter une commande shell (avec capture)
  ansible.builtin.shell:
    cmd: "df -h / | tail -1 | awk '{print $5}'"
  register: disk_usage
  changed_when: false

- name: Afficher l'utilisation disque
  ansible.builtin.debug:
    msg: "Disque utilisé : {{ disk_usage.stdout }}"

Variables, group_vars et host_vars

Les variables permettent de rendre les playbooks génériques et réutilisables. La structure recommandée est :

projet-ansible/
├── inventaire/
│   ├── hosts.yaml
│   ├── group_vars/
│   │   ├── all.yaml          # variables communes à tous
│   │   └── webservers.yaml   # variables pour le groupe webservers
│   └── host_vars/
│       └── web01.yaml        # variables spécifiques à web01
├── playbooks/
│   └── nginx.yaml
├── roles/
│   └── nginx/
└── templates/

Exemple de group_vars/webservers.yaml :

---
nginx_worker_processes: 4
nginx_worker_connections: 1024
app_port: 8080
app_domain: "monsite.exemple.com"

Sécuriser les secrets avec Ansible Vault

Les mots de passe, clés API et autres données sensibles ne doivent jamais apparaître en clair dans vos fichiers YAML. Ansible Vault chiffre ces données avec AES-256 :

# Créer un fichier chiffré
ansible-vault create group_vars/all/vault.yaml

# Chiffrer un fichier existant
ansible-vault encrypt group_vars/all/secrets.yaml

# Modifier un fichier chiffré
ansible-vault edit group_vars/all/vault.yaml

# Exécuter un playbook avec le vault
ansible-playbook -i inventaire/hosts.yaml playbooks/deploy.yaml --ask-vault-pass

# Ou avec un fichier de mot de passe (CI/CD)
ansible-playbook -i inventaire/hosts.yaml playbooks/deploy.yaml --vault-password-file ~/.vault_pass

Organiser avec les rôles

Les rôles sont l’unité de réutilisation d’Ansible : ils encapsulent tâches, handlers, variables, templates et fichiers autour d’une fonctionnalité précise. Créer un rôle avec la commande officielle :

# Initialiser la structure d'un rôle
ansible-galaxy role init roles/nginx

# Structure générée :
roles/nginx/
├── defaults/main.yaml    # variables par défaut (priorité basse)
├── handlers/main.yaml    # handlers
├── meta/main.yaml        # métadonnées du rôle
├── tasks/main.yaml       # tâches principales
├── templates/            # templates Jinja2
├── files/                # fichiers statiques
└── vars/main.yaml        # variables internes (priorité haute)

On intègre ensuite le rôle dans un playbook :

---
- name: Configurer les serveurs web
  hosts: webservers
  become: true
  roles:
    - nginx
    - php-fpm
    - firewall

Bonnes pratiques pour des playbooks en production

• Nommez toutes vos tâches : un name: clair facilite le débogage des logs.
• Utilisez les FQCN (Fully Qualified Collection Names) : préférez ansible.builtin.apt à apt pour éviter les ambiguïtés.
• Validez avec ansible-lint : pip install ansible-lint && ansible-lint playbooks/ détecte les anti-patterns avant exécution.
• Versionner avec Git : chaque modification de playbook doit passer par un commit, de préférence avec une intégration CI/CD (GitLab CI, GitHub Actions).
• Tester avec –check : simulez toujours avant d’appliquer en production.
• Limitez le scope avec –limit : en cas de doute, ciblez un seul hôte (--limit web01) avant de déployer sur tout un groupe.
• Évitez le module shell quand un module dédié existe : ansible.builtin.apt est préférable à shell: apt install nginx car il est idempotent.

À lire également

• Gestion des services avec systemd sur Debian et Ubuntu — comprendre la gestion des services que vos playbooks vont automatiser.
• Authentification par clé publique sur un serveur SSH — prérequis indispensable pour la connexion SSH utilisée par Ansible.
• Docker sur Debian/Ubuntu : installation, configuration et utilisation — combiner Ansible et Docker pour un déploiement complet d’infrastructure.
• Gestion des journaux avec syslog et journalctl — surveiller l’exécution des playbooks et les services déployés via les journaux système.

Références

• Documentation officielle Ansible — Introduction aux Playbooks
• Red Hat — Getting Started with Ansible Playbooks
• Documentation Ansible — Modules built-in
• Spacelift — Ansible Playbooks: Complete Guide with Examples
• Top 10 Ansible Best Practices for Scalable Automation 2026