Playbooks et tasks

Un playbook est un fichier YAML qui décrit un ou plusieurs plays : chaque play cible un groupe de machines (hosts) et exécute une liste de tasks dans l’ordre.

---

Structure minimale

---
- name: Construire l'image PostgreSQL avec health agent
  hosts: all
  become: true
 
  roles:
    - postgresql
    - health-agent

Clé	Rôle
name	Description humaine du play, affichée dans les logs
hosts	Groupe ou machine ciblé (all, web, 10.0.0.5…)
become	Exécute les tasks en sudo (privilege escalation)
roles	Liste de rôles à appliquer, dans l’ordre
tasks	Alternative à roles : liste de tasks directement dans le playbook

---

Anatomie d’une task

- name: Installer PostgreSQL et Python
  ansible.builtin.apt:
    name:
      - postgresql
      - python3
    state: present
    update_cache: true

Une task = un nom lisible + un module (ansible.builtin.apt) + ses paramètres. Le module fait le travail réel ; la task ne fait que l’invoquer avec des arguments.

---

Modules courants

Module	Rôle
ansible.builtin.apt / yum / package	Installer des paquets
ansible.builtin.systemd_service	Gérer un service (enable, start, restart)
ansible.builtin.copy	Copier un fichier tel quel vers la cible
ansible.builtin.template	Copier un fichier après rendu Jinja2 (voir Jinja2 dans Ansible)
ansible.builtin.file	Créer un répertoire, changer des permissions
ansible.builtin.user	Créer/gérer un utilisateur système

---

Idempotence en pratique

- name: Activer et démarrer PostgreSQL
  ansible.builtin.systemd_service:
    name: postgresql
    enabled: true
    state: started

state: started ne redémarre pas un service déjà démarré — le module vérifie l’état réel avant d’agir. Rejouer cette task ne casse rien et n’a aucun effet si le service tourne déjà.

---

En relation avec

• Architecture — Vue d’ensemble — hub architecture
• Roles — organiser des tasks en unités réutilisables
• Variables et handlers — paramétrer les tasks, réagir à un changement