Commencer→
Retour au cours

infra / terraform

Dépendances explicites et implicites

Leçon 111 exercice

Explication

Ce que vous allez apprendre

  • Comprendre comment Terraform déduit automatiquement l'ordre de création des ressources
  • Forcer une dépendance explicite avec depends_on quand aucune référence d'attribut n'existe
  • Visualiser le graphe de dépendances complet d'une configuration
  • Contrôler le parallélisme des opérations pour respecter les limites d'une API cloud
  • Reconnaître le cas classique où une dépendance IAM nécessite depends_on

Dans quel contexte ?

Une équipe déploie une fonction Lambda accompagnée d'une politique IAM qui lui donne le droit d'écrire des logs. Le premier déploiement échoue de façon aléatoire avec une erreur de permissions refusées, alors que le second déploiement, identique, réussit sans problème — un symptôme classique d'un problème d'ordre de création mal anticipé.

D'abord, il faut comprendre comment Terraform déduit l'ordre normalement

Dès qu'une ressource référence un attribut d'une autre (aws_vpc.principal.id dans un sous-réseau, par exemple), Terraform comprend automatiquement qu'il doit créer le VPC AVANT le sous-réseau. Cette dépendance dite "implicite" couvre la grande majorité des cas réels, sans configuration supplémentaire.

Le graphe de dépendances ainsi construit détermine non seulement l'ordre de création, mais aussi l'ordre INVERSE utilisé pour la destruction, et surtout, il révèle quelles ressources sont totalement indépendantes entre elles et peuvent donc être créées EN PARALLÈLE.

Type de dépendanceComment elle se créeDétectée automatiquement ?
ImpliciteRéférence à un attribut d'une autre ressourceOui
Explicite (depends_on)Déclarée manuellement, sans référence d'attributNon, à ajouter soi-même

Prérequis

Cette leçon suppose une bonne compréhension des références entre ressources (type.nom.attribut), vue dans la leçon sur les resources et attributs.

Une fois ce mécanisme automatique compris, pourquoi peut-il parfois échouer silencieusement ?

Le cas du Lambda posé en introduction illustre exactement cette limite : la fonction Lambda référence le RÔLE IAM (aws_iam_role.lambda_role.arn), mais pas la POLITIQUE attachée à ce rôle. Terraform ne voit donc aucune référence directe entre la Lambda et la politique, et peut les créer dans un ordre où la Lambda existe avant que ses permissions ne soient pleinement propagées.

Piège fréquent

Ce genre de bug est particulièrement pernicieux car il est intermittent : parfois la propagation IAM est assez rapide pour que tout fonctionne, parfois non. Un échec qui apparaît "aléatoirement" au premier déploiement d'une ressource liée à IAM est un signal fort qu'une dépendance explicite manque quelque part.

Voici comment on résout ce problème : depends_on

Ajouter depends_on = [aws_iam_role_policy.lambda_policy] force explicitement Terraform à créer la politique AVANT la Lambda, même en l'absence de toute référence d'attribut entre les deux blocs. C'est un mécanisme à utiliser avec parcimonie, réservé aux cas où aucune référence naturelle n'existe.

Il reste un outil précieux pour diagnostiquer visuellement ces relations

Astuce

terraform graph | dot -Tpng > graph.png (avec Graphviz installé) produit une image visuelle complète du graphe de dépendances. Sur une configuration complexe avec des dizaines de ressources, cette visualisation aide à repérer d'un coup d'oeil une dépendance manquante ou un couplage inattendu entre deux modules.

Le piège à connaître avant de continuer

-target=aws_instance.web permet d'appliquer une seule ressource et ses dépendances, mais reste un outil de dépannage exceptionnel : l'utiliser régulièrement en usage courant contourne le graphe de dépendances complet et peut laisser la configuration dans un état partiellement appliqué, difficile à raisonner ensuite.

Ces dépendances bien maîtrisées, la prochaine leçon aborde un sujet controversé de l'écosystème Terraform : les provisioners, et pourquoi il vaut mieux généralement les éviter.

Commandes & code

Dépendances explicites et implicites

hcl
# --- Dépendance IMPLICITE (la plus courante) : Terraform la déduit automatiquement ---
# En référençant un attribut d'une ressource, Terraform sait qu'il doit la créer AVANT
resource "aws_vpc" "principal" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "prive" {
  vpc_id     = aws_vpc.principal.id       # référence -> dépendance implicite : vpc créé avant subnet
  cidr_block = "10.0.1.0/24"
}
hcl
# --- Dépendance EXPLICITE : nécessaire quand il n'y a AUCUNE référence d'attribut ---
# Exemple : une politique IAM doit exister avant qu'une Lambda ne l'utilise via son nom (pas son ID direct)
resource "aws_iam_role_policy" "lambda_policy" {
  name   = "lambda-logs-policy"
  role   = aws_iam_role.lambda_role.id
  policy = data.aws_iam_policy_document.lambda_logs.json
}

resource "aws_lambda_function" "traitement" {
  function_name = "traitement-commandes"
  role          = aws_iam_role.lambda_role.arn

  # Sans référence directe à la policy, Terraform pourrait créer la Lambda AVANT que
  # les permissions IAM soient propagées -> échec transitoire au premier déploiement
  depends_on = [aws_iam_role_policy.lambda_policy]
}
bash
# Visualiser le graphe de dépendances complet
terraform graph | dot -Tpng > graph.png     # nécessite Graphviz (dot) installé
terraform graph                              # sortie brute au format DOT
bash
# Le graphe de dépendances détermine :
# - L'ordre de création (dépendances d'abord)
# - L'ordre de destruction (INVERSE : les dépendants sont détruits avant leurs dépendances)
# - Le PARALLÉLISME : les ressources sans dépendance entre elles sont créées EN PARALLÈLE
bash
# Contrôler le parallélisme (par défaut 10 opérations simultanées)
terraform apply -parallelism=5             # utile si l'API cloud rate-limit les appels concurrents

# Cibler une ressource précise (dépannage, à éviter en usage courant)
terraform apply -target=aws_instance.web    # applique UNIQUEMENT cette ressource et ses dépendances
terraform plan -target=module.vpc            # limite le plan à un module précis
bash
# Piège classique : dépendance implicite manquante détectée SEULEMENT au premier apply "à froid"
# -> une ressource utilise un nom/ARN d'une autre SANS le référencer directement (ex: chaîne codée en dur)
# -> ajouter systématiquement depends_on dans ce cas, ou mieux : référencer l'attribut directement

Résumé

  • Terraform déduit la majorité des dépendances automatiquement dès qu'un attribut est référencé (type.nom.attribut).
  • depends_on force une dépendance explicite quand aucune référence d'attribut n'existe (rare, cas IAM/propagation notamment).
  • Les ressources indépendantes sont créées en parallèle ; -parallelism permet de limiter la charge sur l'API cloud.

Exercices pratiques

1 disponible
1

Mission : traquer une panne IAM intermittente

Objectif : Diagnostiquer une dépendance implicite manquante et la corriger avec un mécanisme explicite, sans abuser des outils de dépannage.

Contexte

Une Lambda aws_lambda_function.traitement référence aws_iam_role.lambda_role.arn, mais aucune référence directe n'existe vers aws_iam_role_policy.lambda_policy. Le premier déploiement échoue par intermittence avec une erreur de permissions refusées ; le second, identique, réussit sans qu'aucune ligne de code n'ait changé entre les deux tentatives.

Résoudre l’exercice →