C'est quoi Ansible ?

Le problème que ça résout

Imagine que tu dois configurer 50 serveurs. Sur chacun, tu dois installer Nginx, créer un utilisateur deploy, copier un fichier de config, activer un service… À la main, c'est des heures de travail, des erreurs inévitables, et une configuration qui dérive dans le temps.

Maintenant imagine faire la même chose en 5 minutes, de façon identique sur tous les serveurs, reproductible à l'infini. C'est exactement ce qu'Ansible permet.

Ansible, c'est quoi exactement ?

Ansible est un outil d'automatisation open source créé en 2012 par Michael DeHaan, racheté par Red Hat en 2015 (aujourd'hui IBM). Il permet de décrire l'état désiré de ton infrastructure en YAML, puis d'appliquer cet état automatiquement sur une ou des centaines de machines.

Sa philosophie est la simplicité : pas de langage de programmation complexe, pas d'agent à installer sur les machines cibles, juste du YAML lisible par un humain.

L'approche agentless

La grande force d'Ansible par rapport à ses concurrents, c'est son architecture agentless. Il n'y a rien à installer sur les machines cibles.

Ansible se connecte simplement via SSH (ou WinRM pour Windows), exécute les tâches, puis se déconnecte. Rien ne tourne en arrière-plan sur le serveur cible. Pas de daemon, pas de certificat à gérer, pas de port supplémentaire à ouvrir.

# Machine de contrôle (ton poste ou un serveur CI)
Machine de contrôle  ──SSH──▶  Serveur 1 (nginx, user deploy)
                     ──SSH──▶  Serveur 2 (nginx, user deploy)
                     ──SSH──▶  Serveur 3 (nginx, user deploy)

# Ansible est installé UNIQUEMENT sur la machine de contrôle
# Les cibles n'ont besoin que d'un accès SSH et de Python

Infrastructure as Code (IaC)

Ansible incarne le principe d'Infrastructure as Code : ta configuration n'est plus dans ta tête ou dans un wiki, elle est dans des fichiers versionnés avec Git. Tu décris ce que tu veux, pas comment l'obtenir.

Ces fichiers s'appellent des playbooks. Un playbook Ansible ressemble à ceci :

---
- name: Configurer les serveurs web
  hosts: web_servers
  become: true

  tasks:
    - name: Installer Nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: S'assurer que Nginx est démarré
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

    - name: Créer l'utilisateur deploy
      ansible.builtin.user:
        name: deploy
        shell: /bin/bash
        groups: www-data

Ce fichier est lisible, versionnable avec Git, et peut être exécuté sur 1 ou 100 serveurs avec la même commande : ansible-playbook mon-playbook.yml.

L'idempotence

C'est l'un des concepts clés d'Ansible. Un playbook est idempotent : tu peux l'exécuter 10 fois de suite, le résultat est toujours le même. Si Nginx est déjà installé, Ansible ne l'installe pas une deuxième fois — il vérifie, constate que c'est bon, et passe à la suite.

Comparaison avec les autres outils IaC

Ansible n'est pas le seul outil d'automatisation. Voici comment il se positionne par rapport aux alternatives :

Cas d'usage concrets

Ansible s'utilise dans une grande variété de contextes. Voici les plus courants :

• Installer et configurer des services : Nginx, Apache, MySQL, Docker, Node.js… sur un ou plusieurs serveurs en une seule commande.
• Gestion des utilisateurs : créer des comptes, ajouter des clés SSH, gérer les droits sudo sur toute une flotte de serveurs.
• Déployer une application : cloner un repo Git, installer les dépendances, relancer le service — automatiquement à chaque release.
• Hardening sécurité : appliquer un CIS Benchmark, désactiver les services inutiles, configurer le pare-feu (UFW/firewalld).
• Mise à jour des paquets : patcher 100 serveurs en parallèle, avec contrôle du redémarrage.
• Provisioning de VMs : configurer une nouvelle machine fraîchement créée par Terraform ou manuellement.