3.1 : Syntaxe YAML pour Ansible, structure d’un playbook

Jusqu’ici, on a donné des ordres ponctuels à la tour, un par un, en ligne de commande. Mais un vrai contrôleur aérien ne réinvente pas ses instructions à chaque avion : il suit des fiches de vol écrites à l’avance, précises, et réutilisables. C’est exactement le rôle d’un playbook.

Un playbook, c’est quoi concrètement ?

Un fichier texte, au format YAML, qui décrit une ou plusieurs actions à effectuer sur un ou plusieurs hôtes. Contrairement à une commande ad-hoc, un playbook peut être enregistré, versionné dans Git, relu, et rejoué à l’identique autant de fois que nécessaire.

Voici le plus simple des playbooks :

---
- name: Vérifier la connectivité des serveurs web
  hosts: webservers
  tasks:
    - name: Envoyer un ping Ansible
      ansible.builtin.ping:

Exécutons-le :

ansible-playbook playbook_ping.yaml -i inventaire.yaml

Décortiquons la structure

Les trois tirets ---

En YAML, --- marque le début d’un document. Ce n’est pas propre à Ansible, c’est une convention YAML standard — mais tous les playbooks Ansible commencent par ça.

Une liste de « plays »

Un playbook est en réalité une liste de plays (remarquez le - juste après ---, qui indique un élément de liste en YAML). Un play, c’est un bloc qui associe un groupe d’hôtes à une série d’actions. Un même playbook peut contenir plusieurs plays à la suite, chacun ciblant des hôtes différents :

---
- name: Préparer les serveurs web
  hosts: webservers
  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present

- name: Préparer les serveurs de base de données
  hosts: databases
  tasks:
    - name: Installer MariaDB
      ansible.builtin.apt:
        name: mariadb-server
        state: present

name : la description humaine

Chaque play et chaque tâche peut (et devrait) avoir un name. Ce n’est pas obligatoire techniquement, mais c’est ce qui s’affiche à l’exécution — un playbook sans name clair devient vite illisible dans les logs.

hosts : qui est ciblé

On y retrouve tout ce qu’on a vu en section 2 : un groupe, un hôte précis, un pattern (webservers:databases), ou all.

tasks : la liste des actions

Une liste de tâches, exécutées dans l’ordre d’écriture, du haut vers le bas. Chaque tâche utilise un module (ping, apt, apache2…) suivi de ses paramètres.

Le nom complet des modules : ansible.builtin.xxx

Vous remarquerez qu’on écrit ansible.builtin.ping plutôt que simplement ping. Les deux fonctionnent, mais le nom complet est la bonne pratique à adopter dès maintenant : il précise explicitement de quelle collection vient le module. On verra les collections en détail avec Ansible Galaxy en section 6, mais autant prendre le bon réflexe dès la première ligne de code plutôt que d’avoir à tout corriger plus tard.

L’indentation : le piège numéro un du débutant

En YAML, l’indentation n’est pas cosmétique : elle définit la structure. Deux espaces de décalage en trop ou en moins, et le fichier change de sens, ou refuse carrément de s’exécuter.

# ✅ Correct : "tasks" aligné avec "hosts", chaque tâche indentée sous la liste
- name: Exemple
  hosts: webservers
  tasks:
    - name: Une tâche
      ansible.builtin.ping:

# ❌ Incorrect : indentation incohérente
- name: Exemple
  hosts: webservers
   tasks:
    - name: Une tâche
        ansible.builtin.ping:

💡 Utilisez toujours des espaces, jamais de tabulations, dans un fichier YAML. La plupart des éditeurs de code (VS Code, par exemple) le font automatiquement, mais mieux vaut vérifier ce réglage avant de passer des heures à chercher une erreur de syntaxe invisible à l’œil.

Ce qu’il faut retenir

• Un playbook est une liste de plays, chaque play associant des hosts à des tasks.
• Les tâches s’exécutent dans l’ordre, du haut vers le bas.
• On préfère toujours le nom complet des modules (ansible.builtin.xxx).
• L’indentation YAML n’est pas un détail esthétique : elle définit la structure du fichier.

Dans la prochaine leçon, on regarde de plus près comment choisir et enchaîner les modules dans une tâche — la logique verbe-nom qu’on avait déjà croisée avec PowerShell.