Pourquoi Ansible ? L'automatisation simplifiée

Tu gères 5 serveurs ? 50 ? 500 ? Peu importe le nombre — dès que tu te connectes en SSH pour taper les mêmes commandes sur plusieurs machines, tu perds du temps et tu prends des risques. Un copier-coller foireux sur le mauvais serveur, et c’est la prod qui tombe.

Ansible résout ce problème. Tu décris l’état que tu veux, tu lances une commande, et Ansible s’occupe du reste. Pas d’agent à installer, pas de serveur central à maintenir, pas de langage ésotérique à apprendre. Juste du YAML et du SSH.

Dans ce premier chapitre, on pose les bases : pourquoi Ansible existe, comment il fonctionne, et comment lancer tes premières commandes.

Pourquoi Ansible est devenu incontournable

Avant Ansible, les équipes ops avaient deux options pour automatiser : les scripts Bash ou des outils comme Puppet/Chef. Chacun avait ses limites.

Les scripts Bash fonctionnent — jusqu’au jour où ils ne fonctionnent plus. Un script de 300 lignes qui boucle sur 50 serveurs en SSH, c’est fragile. S’il plante au serveur 27, tu te retrouves avec la moitié de ton infra dans un état incohérent. Et bonne chance pour le relancer sans tout casser : le script ne sait pas ce qui a déjà été fait.

Puppet et Chef résolvent certains problèmes, mais en créent d’autres. Ils imposent un agent sur chaque machine cible, un serveur central à maintenir, et un langage propriétaire à maîtriser (Puppet DSL ou Ruby pour Chef). C’est lourd.

Ansible prend le meilleur des deux mondes :

• Agentless — il se connecte en SSH, exécute ce qu’il faut, et repart. Rien à installer sur les cibles.
• Idempotent — tu peux relancer un playbook 10 fois, seul ce qui doit changer change. Si Nginx est déjà installé, Ansible passe à la suite.
• Lisible — les playbooks sont en YAML. N’importe qui dans l’équipe peut les lire et les comprendre.
• Sans infrastructure — tu lances Ansible depuis ton laptop. Pas de serveur central, pas de base de données, pas de certificats.

🔥 Cas réel — Une startup avec 80 serveurs EC2 passait 2 jours par mois à appliquer les mises à jour de sécurité manuellement. Avec Ansible, la même opération prend 15 minutes — un playbook, une commande, 80 serveurs mis à jour en parallèle.

💡 Tip DevOps — Ansible n’est pas qu’un outil de config management. Il orchestre aussi des déploiements, provisionne du cloud (AWS, Azure, GCP) et gère des conteneurs. Un seul outil pour tout ton pipeline.

Comprendre l’architecture

L’architecture d’Ansible est volontairement minimaliste. Trois composants suffisent pour démarrer.

Le nœud de contrôle — c’est ta machine (laptop, bastion, runner CI). C’est là que tu installes Ansible et que tu lances les commandes. Elle a besoin de Python et d’un accès SSH aux cibles.

L’inventaire — un fichier qui liste tes machines, organisées en groupes. C’est la réponse à la question “sur quoi je travaille ?”.

Le playbook — un fichier YAML qui décrit l’état souhaité. C’est la réponse à la question “qu’est-ce que je veux ?”.

Quand tu lances un playbook, Ansible se connecte en SSH à chaque machine de l’inventaire, pousse un petit module Python, l’exécute, récupère le résultat, et nettoie derrière lui. Les machines cibles n’ont besoin que de Python (présent par défaut sur toute distro Linux) et d’un accès SSH.

🧠 À retenir — Ansible fonctionne en mode push : c’est toi qui déclenches l’exécution depuis le nœud de contrôle. Pas de daemon qui tourne en permanence sur tes serveurs, pas de “pull” périodique. Tu gardes le contrôle total.

⚠️ Attention — Ansible a besoin de Python sur les machines distantes. Sur des images Docker ultra-minimalistes ou certains appliances réseau, Python peut manquer. Vérifie toujours avant de te lancer.

Commandes essentielles

Avant d’écrire des playbooks, Ansible propose les commandes ad-hoc — des one-liners pour des actions rapides. Parfait pour du dépannage ou des vérifications ponctuelles.

Commence par créer un inventaire minimal :

# inventory.ini
[webservers]
web01 ansible_host=192.168.1.10
web02 ansible_host=192.168.1.11

[databases]
db01 ansible_host=192.168.1.20

[all:vars]
ansible_user=deploy
ansible_python_interpreter=/usr/bin/python3

Ensuite, teste la connectivité avec le module ping (ce n’est pas un ping ICMP — Ansible se connecte en SSH et vérifie que Python fonctionne) :

ansible all -i inventory.ini -m ping

Pour exécuter une commande rapide sur un groupe précis :

# Vérifier l'espace disque sur les serveurs web
ansible webservers -i inventory.ini -m command -a "df -h"

# Installer un paquet avec élévation de privilèges
ansible webservers -i inventory.ini -m apt -a "name=nginx state=present" --become

# Redémarrer un service
ansible webservers -i inventory.ini -m service -a "name=nginx state=restarted" --become

Le flag --become active sudo. Sans lui, Ansible exécute tout avec l’utilisateur SSH standard.

💡 Tip DevOps — Utilise ansible all -i inventory.ini -m setup pour collecter les facts de tes machines (OS, IP, RAM, disques…). Ces facts sont ensuite utilisables comme variables dans tes playbooks. C’est un outil de diagnostic puissant.

Pour aller plus loin, voici la structure d’un premier playbook minimal. Crée un fichier setup.yml :

---
- name: Configuration de base des serveurs web
  hosts: webservers
  become: true
  tasks:
    - name: Installer les paquets essentiels
      apt:
        name:
          - nginx
          - curl
          - vim
        state: present
        update_cache: true

    - name: S'assurer que Nginx tourne
      service:
        name: nginx
        state: started
        enabled: true

Et lance-le :

# D'abord en mode dry-run pour voir ce qui va changer
ansible-playbook -i inventory.ini setup.yml --check --diff

# Puis pour de vrai
ansible-playbook -i inventory.ini setup.yml

⚠️ Attention — Toujours lancer --check --diff avant la vraie exécution, surtout en prod. Le mode check simule l’exécution sans rien modifier. Le flag --diff montre exactement ce qui va changer dans les fichiers.

Cas concret : onboarding de serveurs en entreprise

🔥 Cas réel — Tu rejoins une boîte qui gère 30 serveurs Debian. Chaque nouveau serveur est configuré à la main : création d’utilisateurs, installation des outils de monitoring, configuration du firewall, déploiement des clés SSH de l’équipe. Le process prend 2 heures par serveur et le wiki de documentation est toujours obsolète.

Avec Ansible, tu crées un playbook onboarding.yml qui fait tout ça en un run :

---
- name: Onboarding nouveau serveur
  hosts: new_servers
  become: true
  tasks:
    - name: Créer l'utilisateur deploy
      user:
        name: deploy
        shell: /bin/bash
        groups: sudo
        append: true

    - name: Déployer les clés SSH de l'équipe
      authorized_key:
        user: deploy
        key: "{{ lookup('file', 'keys/' + item + '.pub') }}"
      loop:
        - alice
        - bob
        - charlie

    - name: Installer les outils de monitoring
      apt:
        name:
          - prometheus-node-exporter
          - htop
          - iotop
        state: present
        update_cache: true

    - name: Configurer le firewall UFW
      ufw:
        rule: allow
        port: "{{ item }}"
        proto: tcp
      loop:
        - "22"
        - "80"
        - "443"
        - "9100"

Résultat : un nouveau serveur est opérationnel en 3 minutes au lieu de 2 heures. Et le playbook est la documentation — plus de wiki obsolète.

🧠 À retenir — Un bon playbook remplace à la fois le script d’installation ET la documentation. Si quelqu’un veut savoir comment un serveur est configuré, il lit le playbook.

Pièges fréquents

1. Oublier --become pour les tâches root. Ansible n’utilise pas sudo par défaut. Si tu installes un paquet sans --become, ça plante avec une erreur de permissions. Ajoute become: true au niveau du play ou de la task.

2. Ne pas tester avec --check avant d’exécuter. On l’a dit, mais ça vaut la peine de le répéter. Un playbook mal écrit peut casser des choses. Le dry-run est ton filet de sécurité.

3. Mettre des mots de passe en clair dans les playbooks. Utilise Ansible Vault pour chiffrer les secrets. On verra ça dans un chapitre dédié, mais en attendant, ne commite jamais un mot de passe en clair.

4. Ignorer les erreurs sans les gérer. ignore_errors: true est tentant mais dangereux. Si une tâche échoue, il y a une raison. Utilise plutôt failed_when ou des blocs rescue pour gérer proprement les cas d’erreur.

5. Ne pas versionner ses playbooks. Tes playbooks sont du code. Ils vont dans Git. Point. Chaque changement doit être tracé, reviewé, et réversible.

⚠️ Attention — Ansible exécute les tâches dans l’ordre du fichier. Si tu supprimes une tâche d’un playbook, l’état qu’elle avait créé reste sur les serveurs. Ansible ne “nettoie” pas ce qu’il a fait — il assure seulement que l’état décrit est présent.

Exercice pratique

Installe Ansible sur ta machine et crée un inventaire local pour t’exercer sans serveur distant :

pip install ansible

cat > inventory.ini << 'EOF'
[local]
localhost ansible_connection=local
EOF

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

# Récupère les facts de ta machine
ansible localhost -i inventory.ini -m setup | head -50

# Crée un fichier avec le module copy
ansible localhost -i inventory.ini -m copy \
  -a "content='Hello Ansible!' dest=/tmp/ansible-test.txt"

# Vérifie
cat /tmp/ansible-test.txt

Ensuite, écris un playbook exercice.yml qui :

1. Installe curl et tree
2. Crée un répertoire /tmp/ansible-lab
3. Copie un fichier de bienvenue dedans

Lance-le d’abord avec --check, puis pour de vrai. Observe la différence de sortie entre le premier et le deuxième run (idempotence en action).

À retenir

• Ansible est agentless — SSH + Python suffisent, rien à installer sur les cibles
• L’idempotence est le concept clé — un playbook décrit un état, pas une séquence de commandes
• YAML rend les playbooks lisibles par toute l’équipe, pas seulement l’auteur
• Les commandes ad-hoc sont pratiques pour le dépannage, les playbooks pour tout le reste
• --check --diff avant chaque exécution en prod, toujours
• Git pour versionner tes playbooks — c’est du code, traite-les comme tel

➡️ La suite

Dans le prochain chapitre, on plonge dans les modules essentiels et on écrit un playbook complet pour déployer Nginx avec sa configuration personnalisée.

🚀 Pratique en direct

Envie de tester immédiatement ? Lance le Playground DevOpsLab — un terminal Linux complet dans ton navigateur avec tous les outils pré-installés.

▶ Lancer le Playground