Chapitre 2 — Net Peering full-mesh sur OUTSCALE en Terraform

Ce chapitre interconnecte les 3 Nets créés au Chapitre 1 en mesh complet : A↔B, A↔C, B↔C. Trois peerings, acceptés explicitement, et 18 routes inter-Net (3 tiers × 3 Nets × 2 Nets distants). Le piège central est OUTSCALE-spécifique : sur ce cloud, les peerings intra-compte ne sont pas auto-acceptés — il faut une ressource outscale_net_peering_acceptation séparée, sans quoi les routes pointant vers le peering tombent en blackhole. Public visé : intermédiaire à avancé, avec le Chapitre 2 déployé. À la sortie de ce chapitre, toute VM de Net-A peut joindre toute VM de Net-B et Net-C, et réciproquement.

Ce que vous allez apprendre

Coder les 3 peerings full-mesh en Terraform avec for_each sur des couples ordonnés.
Gérer l'acceptation explicite des peerings via outscale_net_peering_acceptation (piège OUTSCALE n°1 du capstone).
Produire les 18 routes inter-Net sans copier-coller, en aplatissant Nets × Tiers × Distants en une seule map.
Consommer le state du stack 00-nets via data "terraform_remote_state".
Diagnostiquer une route en blackhole (le symptôme qu'on rencontre 1 fois sur 2 quand on porte un module AWS).

Prérequis

Le Chapitre 1 — 3 Nets /22 appliqué sur le compte cible (48 ressources actives).
Backend OOS opérationnel — variables AWS_*_CHECKSUM_* exportées (cf. Chapitre 1).
Familiarité avec for_each sur une map(object) et avec les fonctions merge, flatten, sort.

Le piège n°1 — l'acceptation explicite des peerings

C'est la spécificité OUTSCALE à connaître avant de toucher au code. Sur AWS, un peering VPC créé dans le même compte est auto-accepté ; on déclare une seule ressource aws_vpc_peering_connection et c'est terminé. Sur OUTSCALE, le peering naît en état pending-acceptance, même si la source et l'accepter appartiennent au même compte. Tant qu'il reste dans cet état :

Aucun trafic ne traverse.
Toute outscale_route qui le référence apparaît en état blackhole côté OUTSCALE — la route existe mais le paquet est jeté.
terraform apply réussit sans erreur — le piège est silencieux.

Le fix est une ressource Terraform de plus :

resource "outscale_net_peering" "mesh" {
  for_each        = local.peering_pairs
  source_net_id   = local.nets[each.value.source].net_id
  accepter_net_id = local.nets[each.value.accepter].net_id
  # tags...
}

resource "outscale_net_peering_acceptation" "mesh" {
  for_each       = local.peering_pairs
  net_peering_id = outscale_net_peering.mesh[each.key].net_peering_id
}

La ressource outscale_net_peering_acceptation fait passer le peering en état active. Sans elle, c'est blackhole garanti — j'ai vu cette erreur arriver sur tous les portages depuis AWS, sans exception.

Pourquoi un mesh complet et pas un hub-and-spoke

Trois topologies sont envisageables pour interconnecter trois Nets :

Topologie	Peerings	Pour	Contre
Linéaire A↔B, B↔C	2	Coût peering minimal	A→C transite par B (interdit, le peering OUTSCALE n'est pas transitif)
Hub-and-spoke A↔B, A↔C	2	Centralisation des règles via Net-A	Net-A devient SPOF logique ; même limite de transit
Full-mesh A↔B, A↔C, B↔C	3	Pas de SPOF, latence directe entre n'importe quels Nets	1 peering de plus à payer + à gérer

Le piège des deux premières topologies est la non-transitivité du peering OUTSCALE (et AWS — c'est partagé). Un paquet de Net-A à destination de Net-C ne peut pas rebondir via Net-B même si A↔B et B↔C existent. Sans peering direct A↔C, il faut un NAT applicatif (proxy, load balancer interne) sur le Net pivot, ce qui ajoute une latence et un point de défaillance.

Le full-mesh ferme cette discussion. Sur N Nets, ça fait N×(N-1)/2 peerings — 3 pour N=3, 6 pour N=4, 10 pour N=5. Au-delà de 5-6 Nets, on bascule vers une Transit Gateway (que OUTSCALE n'expose pas en service managé à ce jour — cf. roadmap). Pour le capstone à 3 Nets, le full-mesh reste l'option idéale.

La paramétrisation — couples ordonnés pour l'idempotence

Trois Nets a, b, c produisent trois couples non orientés : {a,b}, {a,c}, {b,c}. L'écueil est de les coder par accident en orienté (a-b, b-a) — Terraform créerait alors deux peerings au lieu d'un. La discipline est de trier lexicographiquement chaque couple :

locals {
  peering_pairs = {
    "a-b" = { source = "a", accepter = "b" }
    "a-c" = { source = "a", accepter = "c" }
    "b-c" = { source = "b", accepter = "c" }
  }
}

La clé <source>-<accepter> reste stable pour la durée de vie du stack. Choisir qui est source et qui est accepter n'a pas d'incidence fonctionnelle (le trafic est bidirectionnel une fois le peering actif) — c'est juste un choix de convention figée pour Terraform.

Les 18 routes inter-Net — un seul `for_each` pour tout générer

Chaque tier (public, private, data) de chaque Net doit pouvoir joindre les CIDR des deux autres Nets. Soit 3 tiers × 3 Nets × 2 Nets distants = 18 routes. À la main, c'est 18 blocs outscale_route quasi identiques — donc une bombe à retardement de cohérence. Le bon pattern est un double for_each aplati :

locals {
  # Pour chaque Net : la liste des CIDR distants à router via leur peering.
  remote_routes = {
    for net_key, net in local.nets : net_key => [
      for other_key, other in local.nets : {
        cidr        = other.cidr
        peering_key = "${sort([net_key, other_key])[0]}-${sort([net_key, other_key])[1]}"
      } if other_key != net_key
    ]
  }

  # Aplatir Nets × Tiers × Distants en une seule map indexée.
  inter_net_routes = merge([
    for net_key, routes in local.remote_routes : {
      for entry in flatten([
        for r in routes : [
          for tier in ["public", "private", "data"] : {
            key         = "${net_key}_${tier}_to_${r.peering_key}"
            net_key     = net_key
            tier        = tier
            cidr        = r.cidr
            peering_key = r.peering_key
          }
        ]
      ]) : entry.key => entry
    }
  ]...)
}

resource "outscale_route" "inter_net" {
  for_each = local.inter_net_routes

  route_table_id       = local.route_tables[each.value.net_key][each.value.tier]
  destination_ip_range = each.value.cidr
  net_peering_id       = outscale_net_peering.mesh[each.value.peering_key].net_peering_id
}

Lisons l'expression. remote_routes["a"] produit la liste des deux Nets distants vus de A : [{cidr="10.11.0.0/22", peering_key="a-b"}, {cidr="10.12.0.0/22", peering_key="a-c"}]. Le inter_net_routes croise ces couples avec les 3 tiers de chaque Net pour produire 18 entrées dont la clé est lisible : a_private_to_a-b, b_data_to_b-c…

La consommation du state du stack `00-nets`

Le stack 05-peering/ ne possède aucune ressource outscale_net ni outscale_route_table — il les emprunte au stack 00-nets/ via le state distant :

data "terraform_remote_state" "nets" {
  backend = "s3"
  config = {
    bucket = "capstone-outscale-tfstate"
    key    = "00-nets/terraform.tfstate"
    region = "eu-west-2"
    endpoints = {
      s3 = "https://oos.eu-west-2.outscale.com"
    }
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    skip_metadata_api_check     = true
    skip_s3_checksum            = true
    use_path_style              = true
  }
}

locals {
  nets         = data.terraform_remote_state.nets.outputs.nets
  route_tables = data.terraform_remote_state.nets.outputs.route_tables
}

Trois bénéfices à découper en stacks :

Cycle de vie indépendant. Vous pouvez terraform destroy le stack 05-peering (~10 secondes) sans toucher aux Nets — pratique pour tester un re-câblage.
Permissions plus fines. Le compte EIM qui pilote 05-peering n'a pas besoin de outscale_net:Create, juste outscale_net_peering:* et outscale_route:*.
Surface de blast réduite. Une erreur dans 05-peering ne peut pas casser les Nets eux-mêmes.

Le prix à payer : vous devez terraform apply les stacks dans l'ordre (00-nets puis 05-peering) et tenir un contrat d'output stable côté 00-nets. C'est un pattern standard de pipeline IaC — il vaut largement le découpage.

Étapes — apply pas à pas

Vérifier que le stack 00-nets est bien applied.
Fenêtre de terminal
```
cd terraform/00-nets/
terraform output -json | jq '.nets.value | keys'
# → ["a", "b", "c"]
```
Si le state est vide, retournez au Chapitre 1.
Initialiser le stack peering.
Fenêtre de terminal
```
cd ../05-peering/
terraform init
```
Le init télécharge le provider 1.5.0 (déjà en cache local depuis le stack précédent) et configure le backend.
Lire le plan — vous devez voir 24 ressources à créer :
- 3 outscale_net_peering (un par couple)
- 3 outscale_net_peering_acceptation (un par peering)
- 18 outscale_route (3 tiers × 3 Nets × 2 Nets distants)
Fenêtre de terminal
```
terraform plan
```
Plan: 24 to add, 0 to change, 0 to destroy.
Appliquer.
Fenêtre de terminal
```
terraform apply
```
Compter ~30 secondes. La création est très rapide — pas d'IGW ni de NAT à provisionner ici.
Vérifier que les 3 peerings sont en active (pas en pending-acceptance).
Fenêtre de terminal
```
oapi-cli ReadNetPeerings --Filters.Tags '["project=capstone"]' \
  | jq '.NetPeerings[] | {tag: (.Tags[] | select(.Key=="Name") | .Value), state: .State.Name}'
```
Doit afficher state: "active" × 3. Si vous voyez pending-acceptance, l'acceptation Terraform a échoué — relire la section piège n°1.

Vérifier que les routes ne sont PAS en blackhole.

oapi-cli ReadRouteTables --Filters.Tags '["project=capstone"]' \
  | jq '.RouteTables[].Routes[] | select(.NetPeeringId != null) | {dest: .DestinationIpRange, peering: .NetPeeringId, state: .State}'

Toutes les entrées doivent avoir state: "active". Si une seule est blackhole, c'est qu'un peering est resté en pending-acceptance.

Validation fonctionnelle — un ping inter-Net

Le seul test qui ne ment pas est de pinger une VM dans Net-B depuis une VM dans Net-A. Vous ferez ce test au Chapitre 4 quand le bastion sera déployé. À ce stade, on se contente de la validation par API — peering active + routes active côté OUTSCALE = trafic théoriquement OK. La validation fonctionnelle viendra avec la première VM joignable.

Pourquoi `for_each` et pas 3 modules

Une variante consisterait à instancier 3 fois un module Terraform peering paramétré par (source, accepter). Le code serait plus court mais le tradeoff penche en faveur du for_each direct :

Lisibilité du plan — un terraform plan montre 3 ressources outscale_net_peering.mesh["a-b"], lisibles d'un coup. Avec un module, c'est module.peering_ab.outscale_net_peering.this × 3, plus verbeux.
Refactor moins coûteux — passer de 3 à 4 Nets ajoute une ligne dans peering_pairs, contre 3 invocations de module supplémentaires.
Pas de plus-value modulaire — la logique tient en 30 lignes ; un module ajouterait une indirection sans encapsuler de complexité réelle.

La règle générale : for_each pour 2-10 instances, module quand on dépasse une centaine de lignes ou qu'on veut publier la logique en réutilisable. Ici, on est très loin du seuil.

Pièges courants

Symptôme	Cause	Solution
Routes en `blackhole` côté API	Peering en `pending-acceptance`	S'assurer que `outscale_net_peering_acceptation` est créée pour chaque peering
`Error: argument min/max requires number` au plan	Comparaison de strings avec `min()`/`max()`	Remplacer par `sort([a, b])[0]` et `sort([a, b])[1]`
Peerings doublés (6 au lieu de 3)	Couples non triés (`a-b` et `b-a`)	Trier lexicographiquement la clé du couple
`Error: data.terraform_remote_state.nets — Output not found`	`00-nets` non appliqué ou clé d'output renommée	Re-`apply` le stack `00-nets`, vérifier les noms d'outputs
`Error: trailing checksum is not supported` au lecteur de state	Variables `AWS__CHECKSUM_` non exportées	`direnv allow` à la racine du dépôt
Trafic OK A→B mais pas B→A	Route manquante côté Net-B	Vérifier que `inter_net_routes` produit bien 18 entrées (6 par Net)

À retenir

Sur OUTSCALE, l'acceptation est explicite, même intra-compte — la ressource outscale_net_peering_acceptation est mandatory.
3 Nets en mesh = 3 peerings + 18 routes (3 tiers × 3 Nets × 2 distants), tout généré par un for_each aplati.
Le peering n'est pas transitif — un mesh complet est requis dès qu'il faut plus que de l'étoile.
HCL ne compare pas les strings avec </>/min()/max() — le pattern idiomatique est sort([a, b])[0].
Le state distant (data.terraform_remote_state) est le contrat propre pour empiler des stacks IaC sans tout fusionner dans un mégastack.
Une route en blackhole est silencieuse côté Terraform — la vérification se fait côté API OUTSCALE après l'apply.

Prochaines étapes

Chapitre 3 — Bastion SSH + EIP fixe attachée Déployer le bastion SSH dans Net-A avec attachement de l'EIP fixe pré-allouée hors Terraform (datasource).

Chapitre 1 — Provisionner les 3 Nets en /22 Le stack 00-nets que ce chapitre consomme via terraform_remote_state.

Référence Terraform OUTSCALE La syntaxe complète des ressources outscale_net_peering, outscale_net_peering_acceptation, outscale_route.

Vue d'ensemble du capstone Revenir au plan global et aux décisions structurantes du projet fil rouge.