🧰 Ansible : configurer ses serveurs de façon reproductible

📚 Introduction

Provisionner une VM, c’est la moitié du travail. Une fois la machine créée — par OpenTofu, ou à la main sur Proxmox —, elle est vide : il faut installer les paquets, créer les utilisateurs, déposer la config, démarrer les services. Si on le fait à la main, en SSH, on retombe dans le piège habituel : personne ne se souvient de la séquence exacte six mois plus tard.

Ansible répond à ce besoin : décrire la configuration d’un serveur dans des fichiers YAML versionnés, et l’appliquer de façon reproductible. La version community ansible 14.2.0 s’appuie sur ansible-core 2.21 (qui demande Python 3.12+ côté contrôleur). C’est un projet open source (GPLv3) porté par Red Hat et une large communauté.

🔎 Pourquoi Ansible est-il « sans agent » ?

C’est sa particularité la plus utile : Ansible n’installe rien de permanent sur les machines gérées. Là où d’autres outils demandent un démon qui tourne en continu sur chaque serveur, Ansible se contente de deux choses déjà présentes partout : un accès SSH et un interpréteur Python. Il se connecte, pousse le module nécessaire, l’exécute, récupère le résultat, et repart.

Concrètement, on installe Ansible sur une seule machine — la tienne, ou un petit contrôleur — et on pilote tout le parc depuis là :

pipx install ansible      # méthode recommandée
# ou
python3 -m pip install --user ansible

🚀 Inventaire et playbook

Deux fichiers suffisent. L’inventaire liste les machines, éventuellement par groupe :

[web]
web1.homelab.lan
web2.homelab.lan

Le playbook décrit l’état souhaité, sous forme de tâches qui appellent des modules. Chaque module (ansible.builtin.apt, ansible.builtin.service…) sait vérifier l’état réel avant d’agir :

- name: Configurer un serveur web
  hosts: web
  become: true
  tasks:
    - name: Installer Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
 
    - name: Démarrer et activer Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
 
    - name: Déposer la page d'accueil
      ansible.builtin.copy:
        src: files/index.html
        dest: /var/www/html/index.html
        mode: '0644'

On vérifie d’abord que les machines répondent, puis on applique :

ansible web -i inventory.ini -m ansible.builtin.ping
ansible-playbook -i inventory.ini site.yml

🧱 L’idempotence, la vraie bonne idée

Le mot fait peur, l’idée est simple : rejouer un playbook ne casse rien. Chaque module compare l’état actuel à l’état demandé et n’agit que si nécessaire. Nginx est déjà installé ? La tâche est marquée ok, rien ne se passe. Le fichier a changé ? La tâche est marquée changed, il est recopié.

Cette propriété change tout par rapport à un script shell classique, où relancer deux fois peut créer des doublons ou planter. Avec Ansible, le playbook n’est pas une suite d’actions, c’est une description de l’état cible : on le rejoue à volonté, sur une machine neuve comme sur une machine déjà à moitié configurée, et on converge toujours vers le même résultat.

⚠️ Quelques précautions

• Nomme les modules en entier (ansible.builtin.copy plutôt que copy). Le nom pleinement qualifié (FQCN) évite les ambiguïtés le jour où une collection tierce expose un module homonyme.
• Ne mets pas de secrets en clair dans les playbooks. Ansible fournit ansible-vault pour chiffrer mots de passe et clés directement dans le dépôt.
• Un serveur configuré par Ansible ne se modifie plus à la main. Comme pour l’IaC en général, toute retouche manuelle crée un écart entre le code et le réel. La règle : on repasse toujours par le playbook.
• Python doit être présent sur la cible. C’est le cas par défaut sur la plupart des distributions Linux, mais à vérifier sur les images minimales.

🎉 Conclusion

Ansible, c’est la config de tes serveurs traitée comme du code : versionnée, relisible, rejouable sans crainte grâce à l’idempotence, et sans agent à maintenir. Le duo qui marche pour un homelab : OpenTofu crée la VM, Ansible la configure. Le jour où tu dois remonter une machine, tu ne cherches plus tes notes — tu lances un playbook, et la machine se reconstruit toute seule.

🔗 Liens utiles

• Ansible — site officiel
• Ansible — documentation
• ansible-core sur PyPI
• Ansible sur GitHub