Unité 2.2 : Réseau et connectivité en tant que code

Introduction

Dans l'unité 2.1, vous avez provisionné la couche de calcul de TaskBoard : un serveur API et un travailleur, chacun démarré avec cloud-init. Ces serveurs sont inutiles tant qu'ils ne peuvent pas communiquer entre eux, accéder à Internet pour les mises à jour des paquets, et résoudre un nom d'hôte qui pointe vers le point de terminaison de l'API. C'est le rôle de la couche réseau, et sur IONOS CLOUD, chaque composant de cette couche est une ressource Terraform.

Cette unité construit la pile réseau sous-jacente à TaskBoard. Vous segmentez le trafic en une couche publique, une couche applicative et une couche de base de données à l'aide de LAN distincts, vous connectez les serveurs à ces LAN à l'aide de NIC, vous accordez aux couches privées un accès sortant contrôlé via une passerelle NAT, et vous publiez un enregistrement DNS afin que les clients puissent trouver l'API. Chaque ressource est déclarative, chaque dépendance est résolue par le graphe de Terraform, et l'ensemble de la topologie est reproductible à partir d'un seul terraform apply.

1. Les LAN pour le cloisonnement réseau

La ressource ionoscloud_lan constitue la base du cloisonnement réseau au sein d'un VDC. Un LAN est un domaine de diffusion de niveau 2 limité à un centre de données. Vous créez un LAN par niveau afin que le trafic entre les niveaux traverse une frontière contrôlée plutôt que de partager un réseau à plat.

L'argument le plus important est public. Un LAN public est connecté à la passerelle internet d'IONOS CLOUD et ses cartes réseau reçoivent une adresse IPv4 publique routable du service DHCP de la plateforme. Un LAN privé (public = false) ne possède pas de chemin internet propre, ce qui est exactement ce que vous souhaitez pour les niveaux d'application et de base de données.

1.1 Définition des trois niveaux

TaskBoard nécessite trois LAN : un LAN public pour l'entrée, un LAN d'application privé pour l'API et le travailleur, et un LAN de base de données privé. Chaque LAN appartient au centre de données que vous avez provisionné dans le Module 1.

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}

resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}

resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Terraform attribue à chaque LAN un identifiant numérique au sein du centre de données une fois celui-ci créé. Vous référencez ces identifiants à partir des ressources NIC plutôt que de les coder en dur, ce qui permet de conserver la configuration portable d'un environnement à l'autre.

1.2 Adressage à l'intérieur d'un LAN

La plateforme attribue à chaque LAN un sous-réseau privé avec une taille de sous-réseau par défaut de /24, de sorte qu'un seul LAN vous offre jusqu'à 254 adresses hôte utilisables. Les LAN privés utilisent les plages RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). La MTU Ethernet standard est de 1500 octets, ce qui est important lorsque vous ajustez les tailles de paquets au niveau de l'application ou les charges utiles VPN plus tard dans cette unité.

Vous ne configurez pas le sous-réseau sur le LAN lui-même. Les adresses sont attribuées au niveau de la NIC, soit automatiquement par DHCP, soit en tant qu'IP statiques explicites, ce que la section suivante aborde.

2. Attacher des serveurs avec des NIC

Un ionoscloud_nic connecte un serveur à un LAN. Un serveur peut avoir plusieurs NIC, et c'est précisément ainsi qu'un hôte participe à plus d'un niveau. Le serveur API de TaskBoard, par exemple, a besoin d'une NIC sur le LAN public (pour recevoir le trafic entrant) et d'une NIC sur le LAN d'application (pour atteindre les niveaux des workers et de la base de données).

La NIC est l'endroit où vous décidez si une interface reçoit une adresse attribuée par DHCP ou une adresse statique, et si le pare-feu de la plateforme est actif sur cette interface.

2.1 Adressage DHCP et statique

Définissez dhcp = true pour permettre au service DHCP de la plateforme d'attribuer une adresse. Sur un LAN public, cela attribue également automatiquement une adresse IPv4 publique routable. Pour les niveaux privés où vous souhaitez des prévisibles, fournissez une liste explicite ips à partir de la plage RFC 1918 du LAN.

# Public-facing NIC on the API server: DHCP-assigned public IP
resource "ionoscloud_nic" "api_public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.public.id
  name          = "api-public"
  dhcp          = true
  firewall_active = true
}

# Private NIC on the API server: static address on the app LAN
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  name          = "api-app"
  dhcp          = false
  ips           = ["10.7.1.10"]
}

L'indicateur firewall_active active le pare-feu par carte réseau. Une fois activé, le pare-feu de la carte réseau bloque par défaut tout le trafic entrant et n'autorise le trafic que sur les ports explicitement activés. Le pare-feu de la carte réseau est le contrôle de sécurité par interface ; la configuration détaillée des règles et les Network Security Groups sont abordés dans l'Unité 2.3.

2.2 Serveurs multi-carte réseau et appartenance à une couche

Le nœud de travail n'a besoin que d'accéder aux couches d'application et de base de données, il dispose donc de deux cartes réseau privées et d'aucune interface publique.

resource "ionoscloud_nic" "worker_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.app.id
  name          = "worker-app"
  dhcp          = false
  ips           = ["10.7.1.20"]
}

resource "ionoscloud_nic" "worker_db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.worker.id
  lan           = ionoscloud_lan.db.id
  name          = "worker-db"
  dhcp          = false
  ips           = ["10.7.2.20"]
}

Étant donné que Terraform détecte que chaque carte réseau fait référence à la fois à un serveur et à un LAN, il ordonne automatiquement la création : d'abord le datacenter, puis les LAN et les serveurs, et enfin les cartes réseau. Vous n'écrivez jamais explicitement depends_on pour cette chaîne. En l'absence de carte réseau publique, le worker est inaccessible depuis Internet, ce qui correspond à l'isolation souhaitée pour un processus en arrière-plan.

3. Accès sortant avec une passerelle NAT

Un LAN privé n'a aucune route vers Internet. C'est favorable à la sécurité des entrées, mais cela pose problème lorsque votre serveur API doit télécharger des mises à jour du système d'exploitation, récupérer des dépendances ou appeler une API SaaS externe. La ressource ionoscloud_natgateway résout ce problème en fournissant une connectivité sortante contrôlée et uniquement sortante.

La passerelle NAT est exclusivement SNAT (Source NAT). Elle réécrit l'adresse source du trafic sortant des hôtes privés vers une IP publique dont la passerelle est propriétaire, et elle bloque automatiquement tout trafic entrant non sollicité. Une passerelle unique peut desservir jusqu'à 6 réseaux privés.

3.1 Provisionnement de la passerelle

La passerelle nécessite une ou plusieurs adresses IPv4 publiques réservées, que vous allouez sous forme de bloc IP. Attachez la passerelle aux LAN dont les hôtes ont besoin d'un accès sortant, et définissez l'IP interne à la passerelle qu'elle utilise sur chaque LAN.

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}

resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips

  lans {
    id           = ionoscloud_lan.app.id
    gateway_ips  = ["10.7.1.1/24"]
  }
}

L'appel API sous-jacent correspond à POST /datacenters/{datacenterId}/natgateways. Comme toutes les opérations de provisionnement d'IONOS CLOUD, celle-ci est asynchrone ; le fournisseur Terraform interroge la requête jusqu'à sa complétion avant de signaler la ressource comme créée.

3.2 Règles SNAT

La passerelle ne transmet pas le trafic tant que vous n'avez pas défini de règles. Une règle de passerelle NAT spécifie quelles adresses sources privées sont traduites et selon quel protocole. Les règles correspondent à POST /datacenters/{datacenterId}/natgateways/{natGatewayId}/rules.

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Le protocole peut être restreint (par exemple à TCP ou UDP) lorsque vous souhaitez un contrôle plus strict, mais ALL est approprié pour une règle de sortie générale. Notez que la route par défaut n'est pas injectée automatiquement : les hôtes du LAN privé doivent utiliser l'adresse IP de la passerelle (10.7.1.1 ci-dessus) en tant que passerelle par défaut, que vous configurez généralement via cloud-init ou les options DHCP sur l'interface réseau.

4. Connectivité de site à site avec IPSec VPN

Lorsque TaskBoard doit accéder à une ressource dans votre centre de données sur site, par exemple un fournisseur d'identité interne, vous reliez les deux réseaux à l'aide de la ressource ionoscloud_vpn_ipsec_gateway. Le VPN Gateway prend en charge IPSec et WireGuard ; cette section utilise IPSec pour un tunnel classique de site à site.

IPSec sur IONOS CLOUD utilise IKEv2 et authentifie les tunnels avec une clé partagée préalable (PSK). L'API VPN est régionale : chaque passerelle est hébergée derrière un hôte spécifique à une région, tel que https://vpn.de-fra.ionos.com, les passerelles IPSec étant exposées au chemin de ressource /ipsecgateways et leurs tunnels étant imbriqués sous /ipsecgateways/{gatewayId}/tunnels.

4.1 Passerelle et tunnel

La passerelle nécessite une IP publique réservée et une connexion vers le LAN qu'elle dessert. Le tunnel définit le pair distant et les sélecteurs de trafic.

resource "ionoscloud_ipblock" "vpn" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-vpn-ip"
}

resource "ionoscloud_vpn_ipsec_gateway" "hybrid" {
  name       = "taskboard-hybrid"
  location   = "de/fra"
  gateway_ip = ionoscloud_ipblock.vpn.ips[0]

  connections {
    datacenter_id = ionoscloud_datacenter.taskboard.id
    lan_id        = ionoscloud_lan.app.id
    ipv4_cidr     = "10.7.1.5/24"  # the gateway's own host address on the app LAN, not the network address
  }
}

resource "ionoscloud_vpn_ipsec_tunnel" "onprem" {
  gateway_id    = ionoscloud_vpn_ipsec_gateway.hybrid.id
  location      = "de/fra"
  name          = "to-onprem"
  remote_host   = "203.0.113.10"

  auth {
    method = "PSK"
    psk {
      key = var.vpn_psk
    }
  }

  cloud_network_cidrs = ["10.7.1.0/24"]
  peer_network_cidrs  = ["192.168.50.0/24"]
}

Gardez la PSK hors du contrôle de source. Déclarez-la en tant que variable sensible (variable "vpn_psk" { sensitive = true }) et fournissez-la via une variable d'environnement ou un magasin de secrets, jamais en tant que littéral dans le fichier .tf.

4.2 Routage à travers le tunnel

Les cloud_network_cidrs et peer_network_cidrs définissent les sous-réseaux accessibles via le tunnel. Le trafic en provenance de 10.7.1.0/24 et à destination de 192.168.50.0/24 est chiffré et transféré ; tout le reste suit le routage normal. Faites correspondre ces CIDRs exactement à votre configuration sur site, car une incompatibilité est la raison la plus fréquente pour laquelle un tunnel est établi mais ne transporte aucun trafic.

5. DNS as Code

Une pile réseau que personne ne peut trouver est incomplète. Les ressources ionoscloud_dns_zone et ionoscloud_dns_record vous permettent de publier le DNS entièrement depuis Terraform, de sorte que le nom d'hôte de l'API de TaskBoard est versionné aux côtés de l'infrastructure qui la sert. IONOS Cloud DNS est servi depuis un réseau Anycast, de sorte que les enregistrements sont résolus depuis le point de présence le plus proche.

5.1 Zones et enregistrements

Créez la zone, puis ajoutez des enregistrements pointant vers l'IP publique allouée à l'interface réseau publique du serveur API.

resource "ionoscloud_dns_zone" "taskboard" {
  name        = "taskboard.example.com"
  description = "TaskBoard application zone"
  enabled     = true
}

resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Les valeurs de TTL doivent se situer entre 60 et 604800 secondes. Cloud DNS prend en charge un large ensemble de types d'enregistrements, notamment A, AAAA, CNAME, ALIAS, MX, NS, SOA, SRV, TXT, CAA et HTTPS. Pour créer un enregistrement apex (racine de zone), laissez le champ du nom d'enregistrement vide au lieu d'utiliser @.

L'appel API correspondant effectue une opération POST vers https://dns.<region>.ionos.com/zones pour les zones et vers le chemin /records de la zone pour les enregistrements, par exemple POST https://dns.de-fra.ionos.com/zones/{zoneId}/records.

5.2 Portée de Cloud DNS et place de la bascule

Cloud DNS est un service DNS autoritatif : il publie et résout vos zones et vos enregistrements. Il n'interroge pas vos backends et n'effectue pas de bascule basée sur des vérifications d'état de santé. Par conséquent, un enregistrement continue de se résoudre vers sa cible configurée, indépendamment de l'état de cette cible. Ne comptez pas sur DNS pour contourner un backend défaillant. Pour une bascule automatique, placez un équilibreur de charge géré devant vos cibles et pointez l'enregistrement DNS vers l'équilibreur de charge, afin que les vérifications d'état de santé et le retrait des cibles s'effectuent au niveau de l'équilibrage de charge présenté dans l'Unité 2.3.

Fiche rapide de référence de l'API

Points de terminaison API principaux pour le provisionnement du réseau et de la connectivité :

URL de base (Cloud API) : https://api.ionos.com/cloudapi/v6 Hôte DNS régional : https://dns.de-fra.ionos.com Hôte VPN régional : https://vpn.de-fra.ionos.com Authentification : Authorization: Bearer <token>

Atelier de code

Objectif : Construire la pile réseau à trois niveaux de TaskBoard avec Terraform : les LAN publiques, d'application et de base de données, les cartes réseau des serveurs, une passerelle NAT pour la sortie privée, et un enregistrement DNS pour l'API. Ensuite, vérifier la connectivité entre les niveaux.

Prérequis :

• Compte IONOS CLOUD avec jeton API (IONOS_TOKEN exporté)
• Terraform avec le fournisseur ionoscloud installé
• Le centre de données et les serveurs de TaskBoard de l'Unité 2.1 déjà dans l'état

Étape 1 : Définir les trois LAN

resource "ionoscloud_lan" "public" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-public"
  public        = true
}
resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app"
  public        = false
}
resource "ionoscloud_lan" "db" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db"
  public        = false
}

Sortie attendue :

Plan: 3 to add, 0 to change, 0 to destroy.

Étape 2 : Attacher les NIC du serveur API

resource "ionoscloud_nic" "api_public" {
  datacenter_id   = ionoscloud_datacenter.taskboard.id
  server_id       = ionoscloud_server.api.id
  lan             = ionoscloud_lan.public.id
  dhcp            = true
  firewall_active = true
}
resource "ionoscloud_nic" "api_app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  dhcp          = false
  ips           = ["10.7.1.10"]
}

Sortie attendue :

ionoscloud_nic.api_public: Creation complete after 1m12s

Étape 3 : Réserver un bloc IP et créer la passerelle NAT

resource "ionoscloud_ipblock" "nat" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-nat-ip"
}
resource "ionoscloud_natgateway" "taskboard" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nat"
  public_ips    = ionoscloud_ipblock.nat.ips
  lans {
    id          = ionoscloud_lan.app.id
    gateway_ips = ["10.7.1.1/24"]
  }
}

Sortie attendue :

ionoscloud_natgateway.taskboard: Creation complete after 2m03s

Étape 4 : Ajouter la règle de sortie SNAT

resource "ionoscloud_natgateway_rule" "app_egress" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  natgateway_id = ionoscloud_natgateway.taskboard.id
  name          = "app-tier-egress"
  type          = "SNAT"
  protocol      = "ALL"
  source_subnet = "10.7.1.0/24"
  public_ip     = ionoscloud_ipblock.nat.ips[0]
}

Sortie attendue :

ionoscloud_natgateway_rule.app_egress: Creation complete

Étape 5 : Publier l'enregistrement DNS

resource "ionoscloud_dns_zone" "taskboard" {
  name    = "taskboard.example.com"
  enabled = true
}
resource "ionoscloud_dns_record" "api" {
  zone_id = ionoscloud_dns_zone.taskboard.id
  name    = "api"
  type    = "A"
  content = ionoscloud_nic.api_public.ips[0]
  ttl     = 300
  enabled = true
}

Sortie attendue :

ionoscloud_dns_record.api: Creation complete

Étape 6 : Appliquer et vérifier la sortie depuis un hôte privé

terraform apply -auto-approve
# SSH to the API server via its public IP, then test outbound through NAT:
ssh root@$(terraform output -raw api_public_ip)
curl -s https://ifconfig.io   # should return the NAT gateway public IP

Sortie attendue :

<the public IP from ionoscloud_ipblock.nat>

Étape 7 : Vérifier la connectivité des niveaux

# From the API server, reach the worker on the app LAN:
ping -c 2 10.7.1.20

Sortie attendue :

2 packets transmitted, 2 received, 0% packet loss

Liste de contrôle de validation :

• [ ] Trois LAN créés (1 public, 2 privés)
• [ ] Le serveur API dispose à la fois d'une carte réseau publique et d'une carte réseau de niveau application
• [ ] L'hôte privé accède à Internet via l'adresse IP publique du NAT
• [ ] Le serveur API et le travailleur communiquent sur le LAN de niveau application
• [ ] L'enregistrement A DNS est résolu vers l'adresse IP publique de l'API

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Erreurs de développement à éviter lors de la configuration réseau sur IONOS CLOUD :

1. S'attendre à ce que les hôtes d'un LAN privé accèdent à Internet sans passerelle NAT

   • Problème : Votre serveur API sur un LAN privé ne peut pas apt update ni appeler des API externes, et les connexions expirient simplement.
   • Pourquoi cela se produit : Un LAN privé (public = false) n'a pas d'itinéraire vers Internet. L'itinéraire par défaut n'est pas injecté automatiquement, même après avoir attaché une passerelle NAT.
   • Correction : Provisionnez un ionoscloud_natgateway avec une règle SNAT, puis orientez la passerelle par défaut des hôtes vers l'IP de la passerelle via cloud-init ou les options DHCP :

   lans {
     id          = ionoscloud_lan.app.id
     gateway_ips = ["10.7.1.1/24"]
   }
   

2. Sélecteurs de trafic VPN non conformes

   • Problème : Le tunnel IPSec apparaît comme actif, mais aucun paquet ne le traverse et les hôtes sur site restent inaccessibles.
   • Cause : cloud_network_cidrs et peer_network_cidrs ne correspondent pas exactement aux sous-réseaux configurés sur le pair distant, de sorte que le trafic n'est pas sélectionné pour le chiffrement.
   • Correction : Aligner précisément les CIDR des deux côtés. Le côté IONOS CLOUD doit lister son propre sous-réseau LAN ainsi que le sous-réseau du pair qui reflète la configuration de l'appareil distant :

   cloud_network_cidrs = ["10.7.1.0/24"]
   peer_network_cidrs  = ["192.168.50.0/24"]
   

3. Utilisation d'une valeur TTL invalide sur un enregistrement DNS

   • Problème : La création d'un enregistrement DNS échoue avec une erreur de validation sur le champ ttl.
   • Cause : La valeur TTL est en dehors de la plage autorisée de 60 à 604800 secondes (par exemple, une valeur ttl = 30 reprise d'un autre fournisseur).
   • Correction : Limiter la valeur TTL à la plage prise en charge :

   resource "ionoscloud_dns_record" "api" {
     ttl = 300   # valid: 60..604800
   }
   

Résumé

Vous pouvez désormais construire un réseau segmenté et complet pour une application, entièrement en tant que code. Les LAN vous offrent une isolation par niveaux, les NIC connectent les serveurs à un ou plusieurs niveaux avec une adressage statique ou DHCP, une passerelle NAT accorde un accès sortant contrôlé aux hôtes privés, une passerelle IPSec établit un pont vers les réseaux sur site, et les enregistrements DNS publient le point de terminaison, le tout déclaré dans Terraform et reproductible à la demande. TaskBoard dispose désormais d'un niveau d'ingress public, d'un niveau d'application privé et d'un niveau de base de données isolé, avec un égress privé et un nom d'hôte API résoluble.

La pile réseau est le substrat sur lequel le reste du Module 2 s'appuie. L'Unité 2.3 ajoute des équilibreurs de charge et des règles de Network Security Group sur ces LAN et NIC, et le Module 4 connecte le code applicatif aux bases de données gérées qui résideront sur le niveau de base de données que vous venez de créer.

Points clés :

• Un ionoscloud_lan par niveau ; public = true se connecte à la passerelle internet, public = false isole le niveau
• Un serveur rejoint plusieurs niveaux en ayant plusieurs ressources ionoscloud_nic, une par LAN
• Les LAN privés ont besoin d'un ionoscloud_natgateway SNAT uniquement pour l'accès sortant, et la route par défaut n'est pas injectée automatiquement
• Le VPN IPSec utilise IKEv2 avec un PSK et exige des sélecteurs de trafic exactement identiques aux deux extrémités
• Les zones DNS et les enregistrements sont des ressources Terraform avec des TTL limités à 60 à 604800 secondes, servis via un réseau Anycast

Terminologie importante :

• LAN : Un domaine de diffusion de niveau 2 limité à un VDC, l'unité de segmentation réseau ; provisionné avec ionoscloud_lan.
• NIC : Une interface réseau attachant un serveur à un LAN ; un serveur avec des NIC sur plusieurs LAN participe à plusieurs niveaux.
• SNAT (Source NAT) : La traduction effectuée par la passerelle NAT, réécrivant les adresses sources sortantes vers une IP publique tout en bloquant le trafic entrant non sollicité.
• Sélecteur de trafic : La paire de CIDR cloud et pair sur un tunnel IPSec qui détermine quel trafic est chiffré et routé à travers le VPN.
• Enregistrement Apex : Un enregistrement DNS à la racine de la zone, créé dans Cloud DNS en laissant le champ du nom d'enregistrement vide.

Prochaines étapes

Continuer l'apprentissage : Unité 2.3 : Équilibrage de charge et sécurité en tant que code

Sujets connexes :

• Unité 2.1 : Calcul et automatisation des serveurs
• Unité 1.2 : Fournisseur Terraform et modèles de base