Tags Ansible : cibler ou ignorer un sous-ensemble de tâches

Les tags Ansible permettent de cibler ou d'ignorer un sous-ensemble de tâches lors de l'exécution d'un playbook. Vous écrivez un playbook complet qui installe + configure + démarre + teste, et au runtime vous décidez de ne lancer que la partie configuration : ansible-playbook site.yml --tags configuration. Pas besoin d'écrire 5 playbooks séparés ni de commenter des blocs entiers.

Cette page couvre tout : la syntaxe d'application, l'exécution sélective via --tags et --skip-tags, les tags spéciaux (always, never, tagged, untagged), l'héritage depuis un play vers ses tâches, et les pièges classiques (tag mal orthographié qui passe silencieusement).

Pressé ? Les patterns tags essentiels

tasks:
  - name: Installer nginx
    ansible.builtin.dnf:
      name: nginx
      state: present
    tags: [install, packages]      # 2 tags simultanés

  - name: Déployer la conf
    ansible.builtin.template:
      src: nginx.conf.j2
      dest: /etc/nginx/nginx.conf
    tags: [config]
    notify: Reload nginx

  - name: Toujours vérifier le service
    ansible.builtin.systemd_service:
      name: nginx
      state: started
    tags: [always]                 # tourne TOUJOURS, même avec --tags=other

  - name: Tâche dangereuse (cleanup destructif)
    ansible.builtin.file:
      path: /var/cache/myapp
      state: absent
    tags: [never, cleanup]         # ne tourne JAMAIS sauf si --tags=cleanup explicite

Lancer sélectivement : ansible-playbook site.yml --tags config (1 tag), --tags "config,install" (plusieurs), --skip-tags cleanup (exclure).

Sécurité non négociable :

• tags: never sur les opérations destructives (cleanup, purge, destroy) — la tâche ne s'exécute que si l'opérateur tape explicitement --tags=cleanup. Empêche l'incident classique « j'ai lancé ansible-playbook et ça a tout supprimé ».
• tags: always sur les vérifications critiques (sécurité, état des services) — tournent même si l'opérateur cible un sous-ensemble.
• Tag mal orthographié = silencieux — --tags=istall au lieu de install n'exécute rien sans warning. Lister vos tags avec ansible-playbook site.yml --list-tags avant un run important.
• Ne pas abuser des tags — une dizaine par playbook max. Au-delà, c'est que votre playbook fait trop de choses ; scinder plutôt qu'empiler les tags.

Ce que vous allez apprendre

• Appliquer un tag à une tâche, un bloc, un play ou un rôle ;
• Exécuter un sous-ensemble avec --tags <liste> ;
• Ignorer des tâches avec --skip-tags <liste> ;
• Les tags spéciaux : always (toujours exécuté), never (jamais sauf demande), tagged, untagged ;
• Le comportement d'héritage d'un tag posé au niveau play ou bloc.

🧪 Lab d'accompagnement

Cette page est jumelée au lab labs/ecrire-code/tags/ dans stephrobert/ansible-training. Détails et commandes en bas de page : Pratiquer dans le lab.

Appliquer un tag

Un tag est une étiquette apposée sur une tâche via tags: :

tasks:
  - name: Installer nginx
    ansible.builtin.dnf:
      name: nginx
      state: present
    tags:
      - install
      - nginx

  - name: Configurer nginx
    ansible.builtin.template:
      src: nginx.conf.j2
      dest: /etc/nginx/nginx.conf
    tags:
      - configuration
      - nginx

  - name: Démarrer nginx
    ansible.builtin.systemd:
      name: nginx
      state: started
    tags:
      - service
      - nginx

Forme courte (un seul tag) :

- name: Installer nginx
  ansible.builtin.dnf:
    name: nginx
  tags: install

Exécuter un sous-ensemble avec --tags

# Exécuter uniquement les tâches taguées 'install'
ansible-playbook site.yml --tags install

# Plusieurs tags : union
ansible-playbook site.yml --tags "install,service"

# Tag unique
ansible-playbook site.yml --tags configuration

Sortie : Ansible exécute uniquement les tâches qui ont au moins un des tags listés. Les autres apparaissent en skipped dans le PLAY RECAP.

Ignorer des tâches avec --skip-tags

# Tout exécuter SAUF les tâches taguées 'install'
ansible-playbook site.yml --skip-tags install

# Plusieurs tags à skip
ansible-playbook site.yml --skip-tags "install,configuration"

Cas typique : sur une fleet déjà installée, vous skippez l'install pour ne refaire que la configuration.

Les tags spéciaux

always

Une tâche taguée always s'exécute toujours, même si vous précisez --tags <autre> :

- name: Vérifier les prérequis (toujours exécuté)
  ansible.builtin.command: which python3
  tags: always

Cas typique : vérifications en début de play (DNS, reachability, version OS) qui doivent toujours tourner.

never

Une tâche taguée never ne s'exécute jamais sauf si vous demandez explicitement son tag :

- name: Reset complet de la base (destructif)
  ansible.builtin.command: dropdb mydb
  tags:
    - never
    - reset-db

Pour la lancer : ansible-playbook site.yml --tags reset-db. Sans --tags reset-db, la tâche est toujours skippée. Idéal pour les opérations destructives que vous voulez pouvoir lancer sciemment.

tagged et untagged

• tagged : matche toutes les tâches qui ont au moins un tag.
• untagged : matche toutes les tâches qui n'ont aucun tag.

# Lancer uniquement les tâches avec au moins un tag
ansible-playbook site.yml --tags tagged

# Lancer uniquement les tâches sans tag
ansible-playbook site.yml --tags untagged

Cas pratique : vérifier qu'aucune tâche n'a été oubliée sans tag pour audit.

Héritage des tags

Un tag posé au niveau play s'applique automatiquement à toutes ses tâches :

- name: Déployer nginx
  hosts: webservers
  become: true
  tags: nginx                 # tag posé au niveau play

  tasks:
    - name: Installer
      ansible.builtin.dnf:
        name: nginx
        state: present
      # hérite implicitement du tag 'nginx'

    - name: Démarrer
      ansible.builtin.systemd:
        name: nginx
        state: started
      tags: service             # ce tag s'AJOUTE au tag 'nginx' hérité

Idem au niveau bloc :

- block:
    - name: Installer A
      ...
    - name: Installer B
      ...
  tags: install                 # s'applique aux deux tâches du block

Et au niveau rôle :

roles:
  - role: nginx
    tags: nginx               # s'applique à toutes les tâches du rôle nginx

Cas pratique — playbook multi-stages

Un playbook avec 4 stages distincts qu'on peut lancer indépendamment :

- name: Déploiement complet
  hosts: webservers
  become: true

  tasks:
    - name: Installer nginx
      ansible.builtin.dnf:
        name: nginx
      tags: install

    - name: Configurer nginx
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      tags: configuration

    - name: Démarrer nginx
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: true
      tags: service

    - name: Tester nginx
      ansible.builtin.uri:
        url: http://localhost
      tags: test

Lancements possibles :

# Tout
ansible-playbook site.yml

# Première install seulement
ansible-playbook site.yml --tags install

# Reconfig + restart
ansible-playbook site.yml --tags "configuration,service"

# Tout sauf tests (pour aller vite)
ansible-playbook site.yml --skip-tags test

# Tests seuls (smoke test post-deploy)
ansible-playbook site.yml --tags test

Lister les tags d'un playbook

Pour voir tous les tags utilisés dans un playbook avant de lancer :

ansible-playbook site.yml --list-tags

Affiche la liste des tags définis. Pratique pour découvrir un playbook hérité.

ansible-playbook site.yml --list-tasks --tags configuration

Liste les tâches qui s'exécuteraient avec --tags configuration, sans rien lancer. Le dry-run des dry-runs.

Conventions de nommage

Privilégiez des tags orthogonaux : nom de service + type d'opération + phase. Évitez les redondances :

Catégorie	Tags typiques
Service	nginx, postgres, redis, firewall
Type d'opération	install, configuration, service, monitoring, test
Phase de déploiement	pre-deploy, deploy, post-deploy, rollback
Environnement	prod, staging, dev (rarement)

Glissez pour voir

Anti-patterns : step1, step2, task42, tmp, xyz. Pas descriptifs.

Pièges fréquents

Symptôme	Cause	Fix
--tags configurations (pluriel) ne fait rien	Typo silencieuse — Ansible ne signale pas	Toujours --list-tags avant pour vérifier
Tag always ignoré quand on utilise --tags X	Faux — always s'exécute aussi	Vérifier que la tâche a bien le tag, pas un bloc parent
Tag never exécuté quand on lance le playbook complet	Faux — never est toujours skippé sauf demande explicite	Vérifier qu'il n'y a pas un autre tag (sans never) sur la tâche
--skip-tags X skippe aussi les tâches taguées always	Faux — always est skippé uniquement par --skip-tags always	Ne pas s'en inquiéter, comportement attendu
Tag posé sur un play, mais des tâches ne sont pas matchées	Vérifiez qu'il n'y a pas un autre play sans tag dans le même playbook	Vérifier la totalité du playbook
Performance : --tags X reste lent	Ansible parse tout le playbook avant de filtrer	Aucun fix simple — accepter le coût de parsing

Glissez pour voir

À retenir

• Un tag est une étiquette apposée sur une tâche, un bloc, un play ou un rôle.
• --tags <liste> exécute uniquement les tâches taguées ; --skip-tags <liste> ignore les tâches taguées.
• Les tags always s'exécutent toujours, never jamais sauf demande explicite.
• Un tag posé au niveau play, bloc ou rôle s'hérite à toutes les tâches enfants.
• --list-tags et --list-tasks --tags X sont les commandes de dry-run pour valider votre intention avant exécution.
• Conventions : tags orthogonaux et descriptifs (service + type d'opération + phase), pas step1/step2.

Pratiquer dans le lab

Cette page a un lab d'accompagnement : labs/ecrire-code/tags/ dans stephrobert/ansible-training. Il contient un README.md guidé, un Makefile (make verify lance les tests), et un challenge final auto-évalué : playbook multi-tags avec always / never / configuration ciblés via --tags configuration.

Premier accès au lab ?

Avant la première utilisation, il faut cloner le dépôt et provisionner les 4 VMs (control-node + web1, web2, db1) — opération à faire une seule fois. Suivez la page Préparer le lab KVM qui couvre git clone, make bootstrap, make provision.

Une fois le lab provisionné :

cd ~/Projets/ansible-training/labs/ecrire-code/tags/

cat README.md           # tuto pas à pas
cat challenge/README.md # consigne du challenge final
pytest -v challenge/tests/   # lancer les tests testinfra

Si les tests passent, vous maîtrisez les concepts couverts dans ce guide. En cas de blocage, docs/troubleshooting.md à la racine du repo couvre les pièges fréquents (rate-limit SSH, clé absente, collection manquante).

Prochaines étapes

Check mode et diff --check (dry-run) et --diff pour valider une modification avant de l'appliquer

Parallélisme et stratégies forks, serial, throttle, strategy : linear, free, host_pinned, debug

Handlers Combiner tags et handlers : --tags configuration déclenche-t-il les handlers ?

×

📖 Voir la documentation →