Définir le réseau d'une application

Introduction

Votre application a besoin d'un espace d'adressage avant de pouvoir fonctionner. Vous allez définir un VPC AWS et un sous-réseau avec Terraform, comparer le réseau déployé avec l'état Terraform et supprimer uniquement le réseau de votre application.

Vous devez déjà connaître le processus init/plan/apply de Terraform, les adresses de ressources et les bases des blocs CIDR des VPC et sous-réseaux AWS. Terminal, les outils Terraform, l'AWS CLI et un réseau de référence distinct sont prêts. Chaque lab démarre de manière indépendante ; vous n'avez pas besoin de ressources d'une VM précédente.

Liens avec les certifications

Aperçu du lab

Définir et déployer le VPC

Dans cette étape, vous allez traduire le plan d'adressage de l'application en une ressource Terraform et inspecter le VPC obtenu.

Ouvrez Terminal. AWS View affiche les ressources réseau actuelles ; utilisez cette vue pour observer la topologie, tandis que la CLI fournit des champs précis et que Terraform gère les modifications. Le réseau existant reference-network appartient à une autre application et doit rester inchangé.

Un VPC est une frontière réseau régionale. Son bloc CIDR définit sa plage d'adresses : 10.62.0.0/16 réserve des adresses pour cette application. Dans Terraform, aws_vpc.application est une adresse de configuration, pas un identifiant AWS. AWS attribue l'identifiant après la création.

Le répertoire application-network contient la configuration préparée du fournisseur. Elle sélectionne le compte fourni et les versions testées des outils. Placez-vous dans ce répertoire :

cd /home/labex/project/application-network

Créez main.tf. Le heredoc avec délimiteur entre guillemets écrit littéralement le HCL suivant jusqu'à HCL ; > crée ou remplace ce fichier. Le tag Name permet de distinguer facilement le réseau de l'application du réseau de référence.

cat > main.tf <<'HCL'
resource "aws_vpc" "application" {
  cidr_block = "10.62.0.0/16"
  tags = {
    Name = "application-network"
  }
}
HCL

Initialisez le répertoire de travail pour sélectionner le fournisseur requis, puis formatez et validez la configuration. La validation contrôle la structure de la configuration ; elle ne prouve pas qu'une ressource existe.

terraform init
terraform fmt
terraform validate

Si init affiche Incomplete lock file information for providers, ce message concerne les sommes de contrôle pour d'autres plateformes. Cette VM préparée utilise linux_amd64 ; poursuivez une fois l'initialisation et la validation réussies.

Examinez un plan. Terraform décrit aussi les paramètres par défaut du VPC ; repérez cidr_block et le tag Name dans l'ajout proposé.

terraform plan

Le récapitulatif final doit indiquer une ressource à ajouter. Appliquez la configuration et saisissez yes lorsque Terraform demande confirmation :

terraform apply

Interrogez le VPC créé. --filters sélectionne le tag de l'application ; --query affiche uniquement l'identifiant et le CIDR. L'identifiant varie, tandis que le CIDR doit être 10.62.0.0/16.

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}'

Observez à nouveau AWS View : le VPC de l'application apparaît à côté du VPC de référence. Le nouveau VPC ne contient actuellement aucun sous-réseau d'application.

Relier un sous-réseau avec une référence de ressource

Dans cette étape, vous allez créer un sous-réseau dans le VPC de l'application et vérifier sa plage d'adresses, sa zone de disponibilité et sa correspondance dans Terraform.

Un sous-réseau appartient à un seul VPC et à une seule zone de disponibilité. Utilisez 10.62.1.0/24, une plage plus petite à l'intérieur du /16 du VPC, dans us-east-1a. Ni ce CIDR ni une zone de disponibilité ne rendent à eux seuls un sous-réseau public ; le routage Internet et les règles d'accès viendront ensuite.

Créez subnet.tf. L'expression aws_vpc.application.id référence la ressource VPC. Terraform utilise cette dépendance pour créer le VPC avant le sous-réseau et obtient automatiquement l'identifiant réel. Vous ne copiez pas un identifiant de la sortie d'une commande dans le HCL.

cat > subnet.tf <<'HCL'
resource "aws_subnet" "application" {
  vpc_id            = aws_vpc.application.id
  cidr_block        = "10.62.1.0/24"
  availability_zone = "us-east-1a"
  tags = {
    Name = "application-subnet"
  }
}

output "vpc_id" {
  value = aws_vpc.application.id
}

output "subnet_id" {
  value = aws_subnet.application.id
}
HCL

Formatez et validez le nouveau fichier, puis examinez le plan. Il doit ajouter un sous-réseau et exposer deux sorties, sans remplacer votre VPC.

terraform fmt
terraform validate
terraform plan

Appliquez et confirmez avec yes :

terraform apply

Enregistrez et affichez les identifiants générés. $(...) capture la sortie d'une commande ; terraform output -raw renvoie une chaîne sans guillemets.

VPC_ID=$(terraform output -raw vpc_id)
echo "$VPC_ID"
SUBNET_ID=$(terraform output -raw subnet_id)
echo "$SUBNET_ID"

Interrogez AWS indépendamment. Le champ VPC du sous-réseau doit correspondre à l'identifiant du VPC affiché, son CIDR doit être 10.62.1.0/24 et sa zone de disponibilité doit être us-east-1a.

aws ec2 \
  describe-subnets \
  --subnet-ids "$SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}'

L'état Terraform associe les adresses de configuration aux ressources déployées. Inspectez cette correspondance ; comparez les identifiants du VPC et du sous-réseau avec AWS au lieu de considérer une entrée dans l'état comme la preuve d'un réseau fonctionnel.

terraform state list
terraform state show aws_subnet.application

La liste contient aws_vpc.application et aws_subnet.application. Vérifiez maintenant la convergence :

terraform plan

Le résultat attendu est No changes. Dans AWS View, le sous-réseau de l'application apparaît dans le VPC auquel il appartient, à côté du réseau de référence resté intact.

Supprimer uniquement le réseau de l'application

Dans cette étape, vous allez examiner l'ordre de suppression, détruire votre pile Terraform et confirmer que le réseau de référence est conservé.

Terraform utilise le même graphe de dépendances en sens inverse : il supprime le sous-réseau avant le VPC. Un plan de destruction couvre les ressources gérées par ce répertoire de travail ; le réseau de référence préparé séparément ne doit donc pas y apparaître.

Examinez les suppressions prévues :

terraform plan -destroy

Deux ressources doivent être à détruire. Vérifiez les adresses des ressources avant de poursuivre. Détruisez ensuite le réseau de l'application et saisissez yes :

terraform destroy

Interrogez les ressources de l'application par tag. Les deux requêtes doivent renvoyer des listes vides ; une requête qui échoue ne prouve pas la suppression.

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].VpcId'
aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=application-subnet \
  --query 'Subnets[].SubnetId'

Confirmez que Terraform ne gère plus aucune ressource :

terraform state list

La commande n'affiche aucune adresse de ressource. Inspectez enfin le sous-réseau de référence conservé :

aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=reference-subnet \
  --query 'Subnets[].{CIDR:CidrBlock,Zone:AvailabilityZone}'

Son CIDR reste 10.90.1.0/24 dans us-east-1b. AWS View affiche désormais uniquement le réseau de référence. Vos fichiers HCL restent disponibles pour examen même si les ressources de l'application ont été supprimées.

Résumé

Vous avez défini un VPC et un sous-réseau en HCL, utilisé une référence de ressource pour les relier, comparé les champs réels du réseau AWS avec l'état Terraform et confirmé un plan sans modification. Vous avez ensuite supprimé uniquement votre réseau géré et préservé un réseau de référence indépendant. Le routage et les règles de sécurité constituent des étapes distinctes pour rendre une application accessible.