Inventaire et premiers playbooks

Pourquoi Ansible plutôt qu'un script bash

Un script bash exécuté sur 20 serveurs pose un problème : que se passe-t-il s'il échoue au serveur 12 ? Faut-il relancer sur les 20, ou seulement sur les 8 restants ? Ansible résout ça avec des playbooks déclaratifs et idempotents (rejouer un playbook ne casse rien s'il a déjà été appliqué).

Sans agent : juste SSH

Contrairement à d'autres outils qui nécessitent d'installer un agent sur chaque serveur géré, Ansible se connecte simplement en SSH et exécute des modules Python à distance. Rien à installer côté serveur géré, seulement sur la machine de contrôle.

L'inventaire : quels serveurs gérer

[web]
web1.exemple.com
web2.exemple.com

[db]
db1.exemple.com ansible_host=10.0.1.5

[production:children]
web
db

L'inventaire liste les serveurs, groupés par rôle (web, db), avec la possibilité de créer des groupes de groupes (production).

Un premier playbook

---
- name: Installer nginx sur les serveurs web
  hosts: web
  become: true
  tasks:
    - name: Installer le paquet nginx
      apt:
        name: nginx
        state: present

    - name: Démarrer et activer nginx
      service:
        name: nginx
        state: started
        enabled: true

ansible-playbook -i inventaire.ini playbook.yml

L'idempotence : rejouer sans risque

Exécuter ce playbook une deuxième fois ne réinstalle pas nginx s'il est déjà présent, et ne le redémarre pas s'il tourne déjà. Ansible vérifie l'état actuel avant d'agir : c'est ce qui rend les playbooks sûrs à rejouer régulièrement.

Cas concret

Une équipe gère 15 serveurs web configurés manuellement au fil des années, chacun légèrement différent. Un playbook Ansible standardisé est écrit et appliqué à tous : les serveurs déjà conformes ne sont pas modifiés (idempotence), seuls ceux qui divergent sont corrigés pour converger vers la configuration cible, en une seule commande.

Erreurs fréquentes

• Écrire des tâches non idempotentes (ex. un shell: echo texte >> fichier qui ajoute la ligne à chaque exécution) : casse la garantie de rejouabilité sans risque.
• Oublier become: true pour des tâches nécessitant les droits root, causant des échecs de permission.
• Gérer un inventaire à la main sans le versionner dans Git, perdant la traçabilité des changements d'infrastructure.

À retenir

• Ansible fonctionne en SSH pur, sans agent à installer sur les serveurs gérés.
• Un playbook est idempotent : le rejouer ne modifie que ce qui diverge de l'état cible.
• L'inventaire groupe les serveurs par rôle, avec des groupes de groupes possibles.

Mini-exercice

Un playbook installe nginx et le démarre. Il est exécuté une deuxième fois sur un serveur où nginx tourne déjà. Que se passe-t-il ?

Réponse : rien de visible ne change : Ansible constate que le paquet est déjà présent et le service déjà démarré, et ne relance ni l'installation ni le redémarrage. C'est le principe d'idempotence.