Premier playbook

Un playbook est un fichier YAML qui décrit une série de tâches à exécuter sur un groupe d'hôtes. C'est l'unité de travail fondamentale d'Ansible. Comprendre sa structure et son comportement dès le départ évite beaucoup de pièges.

Structure d'un playbook

Un playbook contient un ou plusieurs plays. Chaque play cible un groupe d'hôtes et définit une liste de tasks. Chaque task appelle un module.

---
- name: Déployer nginx
  hosts: web
  become: true

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

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

    - name: Déployer la page d'accueil
      ansible.builtin.copy:
        content: "<h1>OK</h1>"
        dest: /var/www/html/index.html
        owner: www-data
        group: www-data
        mode: "0644"

Quelques points clés :

• hosts : groupe d'hôtes ciblé (doit exister dans l'inventaire)
• become: true : élévation sudo pour toutes les tâches du play
• name : obligatoire pour chaque tâche, sert dans les logs et le debugging
• Le préfixe ansible.builtin. est optionnel mais recommandé pour la lisibilité

Exécuter un playbook

ansible-playbook playbooks/site.yml

Options utiles :

# Vérification syntaxique (ne contacte pas les hôtes)
ansible-playbook playbooks/site.yml --syntax-check

# Dry-run : simule les changements sans les appliquer
ansible-playbook playbooks/site.yml --check

# Dry-run avec diff des fichiers modifiés
ansible-playbook playbooks/site.yml --check --diff

# Cibler un sous-ensemble d'hôtes
ansible-playbook playbooks/site.yml --limit web01.example.com

# Verbosité progressive
ansible-playbook playbooks/site.yml -v    # tâches
ansible-playbook playbooks/site.yml -vv   # + fichiers
ansible-playbook playbooks/site.yml -vvv  # + connexions SSH
ansible-playbook playbooks/site.yml -vvvv # + tout

Lire la sortie

Ansible affiche chaque tâche avec son résultat :

• ok : la tâche a été exécutée, l'état était déjà correct (aucun changement)
• changed : la tâche a modifié quelque chose
• skipping : la tâche a été ignorée (condition when non satisfaite)
• failed : la tâche a échoué, le play s'arrête sur cet hôte
• unreachable : SSH impossible

Le récapitulatif final (PLAY RECAP) donne le bilan par hôte.

L'idempotence : le principe central

Relancer le playbook ci-dessus une deuxième fois sans rien changer sur les serveurs doit produire un PLAY RECAP avec changed=0. C'est le principe d'idempotence : l'outil vérifie l'état actuel et n'agit que si nécessaire.

C'est cette propriété qui rend Ansible fiable en production : on peut relancer un playbook après un incident partiel sans craindre d'effets de bord.

Les modules Ansible garantissent l'idempotence. En revanche, les modules command et shell ne l'implémentent pas automatiquement : si on exécute echo foo >> /etc/fichier via le module shell, chaque run ajoutera une ligne. C'est le cas où changed_when: false ou une condition when est nécessaire.

Variables et templates dans un playbook

Un premier usage des variables directement dans le playbook :

---
- name: Configurer l'application
  hosts: app
  become: true
  vars:
    app_port: 8080
    app_user: appuser

  tasks:
    - name: Créer l'utilisateur applicatif
      ansible.builtin.user:
        name: "{{ app_user }}"
        system: true
        shell: /usr/sbin/nologin

La syntaxe {{ variable }} est du Jinja2 — le moteur de templating utilisé partout dans Ansible. Les guillemets autour de la valeur sont requis dès que la ligne commence par {{ pour que le parseur YAML ne confonde pas avec un dictionnaire.