Playbook Ansible : écrire plays, tasks et handlers

Un playbook Ansible est un fichier YAML qui décrit, sous forme de plays, les tâches à exécuter sur un groupe d'hôtes pour les configurer et les déployer de façon idempotente. Cette sous-section couvre l'écriture des playbooks au-delà du cas trivial. Vous y apprenez la structure d'un play complet (avec pre_tasks, post_tasks, handlers, roles, environment), la vue d'ensemble des collections built-in, le déclenchement précis des handlers via notify: et listen:, l'usage des tags pour cibler un sous-ensemble de tâches, le check mode pour les dry-runs, le parallélisme (forks, serial, strategy), les tâches asynchrones et la délégation (delegate_to, run_once).

C'est la couche opérationnelle de l'écriture de code Ansible, celle où vous passez du "playbook qui marche" au "playbook qui passe à l'échelle, gère les erreurs, et tourne en CI".

Cette page fait partie de la formation Ansible, le hub qui couvre Ansible de la découverte à la certification.

Ce que vous allez apprendre

• L'anatomie complète d'un play et de ses 12 mots-clés (hosts, become, gather_facts, vars, vars_files, pre_tasks, tasks, post_tasks, handlers, roles, environment, strategy) ;
• Les collections built-in : ansible.builtin, ansible.posix, community.general, quoi prendre où ;
• Les handlers et leur déclenchement (notify:, listen:, meta: flush_handlers) ;
• Les tags pour exécuter ou ignorer des sous-ensembles de tâches (--tags, --skip-tags, always, never) ;
• Le check mode (--check) et le diff mode (--diff) pour les dry-runs sécurisés ;
• Le parallélisme : forks, serial (rolling updates), throttle, strategy: linear|free|host_pinned ;
• Les tâches asynchrones : async:, poll:, async_status pour les opérations longues ;
• La délégation : delegate_to, local_action, run_once (cas typique : drain de load-balancer).

Prérequis

• Avoir lu les pages YAML pour Ansible, Structure d'un projet et Style guide de la sous-section Fondations ;
• Avoir validé le premier playbook (anatomie de base, idempotence).

Le parcours en 9 pages

Plays et tasks Anatomie complète d'un play : hosts, become, vars, pre_tasks, tasks, post_tasks, handlers, roles, environment, strategy

Modules built-in Vue d'ensemble des collections ansible.builtin, ansible.posix, community.general, quoi prendre où

Handlers Déclenchement par notify:, écoute par listen:, flush_handlers, pattern restart-on-config-change

Tags Cibler un sous-ensemble : --tags, --skip-tags, tags spéciaux always, never, tagged, untagged

Check mode et diff --check (dry-run), --diff, check_mode: true|false par tâche, modules qui ne supportent pas check_mode

Parallélisme et stratégies forks (CLI, ansible.cfg), serial (rolling), throttle, strategy: linear/free/host_pinned, max_fail_percentage

Async et poll Tâches longues : async:, poll:, async_status, fire-and-forget, attendre la fin

Délégation delegate_to, delegate_facts, local_action, run_once, drain de load-balancer, base de données one-shot

Import vs Include import_tasks vs include_tasks (static vs dynamic), import_role/include_role, import_playbook, les 5 directives EX294 + propagation tags/when

La place dans la RHCE EX294

Objectif RHCE	Couvert par
Créer playbooks simples et avancés	Plays et tasks
Connaître les modules de base	Modules built-in
Utiliser handlers	Handlers
Utiliser tags	Tags
Mode check et diff	Check mode et diff
Gérer le parallélisme	Parallélisme et stratégies
Gérer le rolling update	Parallélisme et stratégies (serial:)
Réutiliser du code (import_* / include_*)	Import vs Include

Glissez pour voir

L'asynchrone et la délégation ne sont pas explicitement à l'examen mais sont indispensables en production réelle.

FAQ : questions fréquentes

Un playbook Ansible, c'est quoi ?

Un playbook Ansible est un fichier YAML qui décrit une série de plays. Chaque play associe un groupe d'hôtes à une liste de tâches (modules) à exécuter pour configurer ou déployer. Les playbooks sont idempotents : les rejouer ne change rien si l'état voulu est déjà atteint.

Quelle différence entre un playbook et un rôle Ansible ?

Un playbook orchestre l'exécution (quels hôtes, dans quel ordre). Un rôle est un bundle réutilisable et structuré (tasks, handlers, vars, templates, defaults) qu'un playbook inclut. En résumé : le playbook décide, le rôle empaquette la logique réutilisable.

Comment exécuter un playbook Ansible ?

Utilisez la commande ansible-playbook avec un inventaire et le fichier du playbook : ansible-playbook -i inventory.ini site.yml. Vous pouvez cibler des hôtes avec --limit, n'exécuter que certaines tâches avec --tags, et augmenter le détail avec -v.

Quelle est la structure d'un playbook Ansible ?

Un playbook est une liste de plays. Chaque play définit hosts (cible), des options comme become (privilèges) et vars, puis tasks (les modules à exécuter) et handlers (tâches déclenchées par notify). On peut aussi inclure des roles, pre_tasks et post_tasks.

Comment tester un playbook sans rien modifier ?

Lancez-le en check mode (dry-run) avec --check : Ansible simule l'exécution sans appliquer de changement. Ajoutez --diff pour voir précisément ce qui serait modifié (contenu de fichiers, lignes de config). C'est la façon sûre de valider avant la vraie exécution.

Quelle différence entre un playbook et une commande ad hoc Ansible ?

Une commande ad hoc (ansible -m) exécute une action unique et ponctuelle, non versionnée. Un playbook est un fichier YAML réutilisable et idempotent qui décrit un état complet. L'ad hoc sert à dépanner vite, le playbook à automatiser durablement.

Comment n'exécuter qu'une partie des tâches d'un playbook ?

Étiquetez les tâches avec tags:, puis lancez ansible-playbook --tags deploy pour ne jouer que celles-ci, ou --skip-tags pour les exclure. Le tag always est toujours joué, never jamais sauf demande explicite.

Comment réutiliser des tâches entre plusieurs playbooks ?

Externalisez les tâches dans un fichier et incluez-le avec import_tasks (statique, résolu au parsing) ou include_tasks (dynamique, résolu à l'exécution). Pour un ensemble complet réutilisable, préférez un rôle appelé via roles: ou include_role.

Ansible et ses playbooks sont-ils gratuits ?

Oui. Ansible est open source sous licence GPLv3 : le moteur ansible-core et l'écriture de playbooks sont gratuits. Red Hat vend Ansible Automation Platform (interface, RBAC, support), mais elle n'est pas nécessaire pour écrire et exécuter des playbooks.

×

📖 Voir la documentation →