Dépendances entre rôles Ansible : meta/main.yml dependencies

Un rôle peut dépendre d’autres rôles via meta/main.yml. Avant que tasks/main.yml du rôle s’exécute, les dépendances tournent en cascade. Pattern utile pour : firewall_setup avant webserver, selinux_setup avant httpd. Cette page démontre le pattern, l’ordre exact de chargement, et les anti-patterns à éviter.

Pressé ? Les dépendances de rôles

roles/webserver/meta/main.yml

---
galaxy_info:
  role_name: webserver
  # ...
dependencies:
  - role: firewall_setup        # joué AVANT tasks/main.yml du webserver
    vars:
      firewall_open_ports:
        - { port: 80, proto: tcp }
        - { port: 443, proto: tcp }

  - role: selinux_setup
    vars:
      selinux_booleans:
        - httpd_can_network_connect

  - role: tls_certs
    when: webserver_tls_enabled | default(false)

Sécurité non négociable :

• Limiter la profondeur des dépendances à 2 niveaux maximum — au-delà, la résolution devient illisible et le debug atroce. Si vous avez besoin de plus, scinder en collections.
• Pas de dépendances circulaires — Ansible détecte et plante, mais ce piège tend à apparaître quand on refactor. Vérifier la chaîne avant de pousser.
• Préférer les collections aux dépendances pour la modularité — une collection avec plusieurs rôles indépendants > un rôle géant avec 5 dépendances.
• allow_duplicates: true dans meta/main.yml du rôle parent si vous voulez l’inclure plusieurs fois avec des params différents (cas du déploiement multi-vhosts) — sinon Ansible skippe la 2ᵉ inclusion silencieusement.

Ce que vous allez apprendre

• Déclarer des dépendances dans meta/main.yml.
• L’ordre exact de chargement (dependencies → tasks → handlers).
• Passer des variables aux dépendances.
• allow_duplicates pour ré-exécuter un rôle avec des params différents.
• Anti-patterns : profondeur excessive, dépendances circulaires.

Le fichier meta/main.yml

roles/webserver/meta/main.yml

---
galaxy_info:
  ...

dependencies:
  - role: selinux_setup
    vars:
      selinux_state: enforcing

  - role: firewall_setup
    vars:
      firewall_zones:
        - public

Ordre d’exécution :

1. selinux_setup (1ère dépendance)
2. firewall_setup (2ème dépendance)
3. Puis webserver/tasks/main.yml

Les dépendances tournent avant le rôle qui les déclare.

Cascade des dépendances

playbook.yml appelle webserver
  ├── webserver/meta/main.yml dependencies:
  │   ├── selinux_setup
  │   │   └── selinux_setup/tasks/main.yml
  │   └── firewall_setup
  │       └── firewall_setup/tasks/main.yml
  └── webserver/tasks/main.yml

Si selinux_setup lui-même déclare des dépendances, elles tournent avant lui — récursion en profondeur.

Limite recommandée : 2 niveaux

Maximum 2 niveaux de profondeur. Au-delà, debug devient un cauchemar : qui appelle qui, quelle variable vient d’où. Préférer un playbook orchestrateur qui appelle les rôles à plat.

Passer des variables aux dépendances

dependencies:
  - role: firewall_setup
    vars:
      firewall_zones:
        - public
        - dmz
      firewall_open_services:
        - http
        - https

Les variables passées au niveau de la dépendance ont priorité élevée — équivalent au vars: sur un roles: classique. Surchargent les defaults/ du rôle dépendant.

Conditionner une dépendance

Pas possible directement dans dependencies: — pas de when: au niveau meta.

Workaround : conditionner dans le rôle dépendant lui-même :

roles/firewall_setup/tasks/main.yml

- name: Configurer firewalld
  ansible.builtin.systemd_service:
    name: firewalld
    state: started
  when: firewall_enabled | default(true)

Ou utiliser include_role avec when: au lieu de dependencies si c’est conditionnel.

allow_duplicates: true — ré-exécuter avec params différents

Par défaut, un rôle n’est exécuté qu’UNE FOIS dans un play, même s’il est listé plusieurs fois (déduplication automatique). Pour forcer la ré-exécution :

roles/database/meta/main.yml

allow_duplicates: true

Permet :

roles:
  - role: database
    vars: { db_name: prod, db_port: 5432 }
  - role: database
    vars: { db_name: staging, db_port: 5433 }   # ← exécuté car allow_duplicates: true

Sans allow_duplicates: true, le second appel serait ignoré.

Anti-patterns à éviter

Anti-pattern 1 — Profondeur excessive

webapp → webserver → tls_config → ca_setup → root_ca_distrib

5 niveaux de profondeur. Debug = horreur. Préférer :

# playbook.yml — orchestrateur
- hosts: all
  roles:
    - root_ca_distrib
    - ca_setup
    - tls_config
    - webserver
    - webapp

À plat. Plus lisible.

Anti-pattern 2 — Dépendances circulaires

A dependencies: [B]
B dependencies: [C]
C dependencies: [A]

Ansible refuse — erreur recursive role dependency. À détecter via ansible-galaxy install -r requirements.yml qui valide le graphe.

Anti-pattern 3 — Tout dans dependencies

Mettre toutes les briques de la stack en dependencies du rôle principal :

roles/webapp/meta/main.yml

dependencies:
  - role: nginx
  - role: php-fpm
  - role: postgresql
  - role: redis
  - role: certbot

Mauvais : le rôle webapp devient inutilisable seul (toutes les deps sont obligatoires). Préférer un playbook qui orchestre.

Le pattern import_role: ou include_role: au lieu de dependencies:

Souvent plus propre d’appeler les rôles depuis le playbook plutôt que via dependencies: :

playbook.yml

- hosts: webservers
  tasks:
    - name: Setup SELinux
      ansible.builtin.import_role:
        name: selinux_setup

    - name: Setup firewall
      ansible.builtin.import_role:
        name: firewall_setup

    - name: Deploy webserver
      ansible.builtin.import_role:
        name: webserver

Avantages :

• Visibilité : le playbook montre l’ordre clairement.
• Conditionnel possible avec include_role + when:.
• Modulaire : webserver peut être utilisé seul (sans déclencher selinux).

dependencies: reste valable pour des dépendances structurelles (ex : un rôle nginx-tls dépend nécessairement de nginx-base).

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/roles/dependencies/ dans stephrobert/ansible-training.

Le lab pose un rôle webserver avec 2 dépendances (selinux_setup + firewall_setup). Les rôles dépendants sont créés. 5 tests structure validés.

cd ~/Projets/ansible-training/labs/roles/dependencies/

cat roles/webserver/meta/main.yml      # déclare les deps
ls roles/                               # webserver + selinux_setup + firewall_setup
pytest -v challenge/tests/              # 5 tests

Pièges courants

Symptôme	Cause	Fix
recursive role dependency	Cycle dans le graphe	Refactorer pour casser le cycle
Dépendance ignorée silencieusement	Déjà jouée dans le même play (déduplication)	allow_duplicates: true si volontaire
Variables des deps en collision	Préfixage absent	Préfixer <role>_* dans chaque rôle
Profondeur > 2 niveaux	Architecture mal pensée	Bouger vers playbook orchestrateur
when: sur dep ignoré	Pas supporté au niveau meta	Conditionner dans le rôle dépendant

Glissez pour voir

À retenir

• meta/main.yml dependencies: chaîne les rôles avant tasks/main.yml.
• Ordre : dependencies (récursif) → tasks → handlers.
• vars: sur dep = priorité haute, surcharge defaults.
• allow_duplicates: true force la ré-exécution avec params différents.
• Max 2 niveaux de profondeur — sinon préférer un playbook orchestrateur.
• import_role/include_role dans le playbook = alternative plus visible.

Prochaines étapes

ansible-galaxy CLI Installation, listing, suppression de rôles via la CLI

Installer des rôles Galaxy requirements.yml + sources Git + pinning de version

Auditer un rôle existant Avant d'ajouter un rôle Galaxy en dépendance, l'auditer

Consommer un rôle Alternatives à dependencies: import_role / include_role

×

📖 Voir la documentation →