Lancer une application initialisée au démarrage

Introduction

Une instance en cours d'exécution n'est utile que si son application s'est initialisée correctement. Vous allez utiliser Terraform pour lire une AMI d'application préparée, lancer une instance EC2 dans le réseau fourni et configurer l'application au moyen de User Data.

Vous devez connaître les variables et les références de ressources Terraform, le routage des sous-réseaux publics, les groupes de sécurité et les bases du lancement d'instances EC2. Cet environnement neuf fournit l'AMI, la paire de clés, le réseau et une application de référence distincte. Vous créerez et supprimerez votre propre instance d'application.

Liens avec les certifications

Aperçu du lab

Lire une AMI et lancer l'application

Dans cette étape, vous allez relier une AMI préparée, des entrées réseau et User Data à une ressource EC2 Terraform, puis vérifier la réponse de l'application initialisée.

Ouvrez Terminal et AWS View. Le serveur de référence est déjà en cours d'exécution. Le réseau de l'application est prêt, mais aucun application-server n'existe encore. Ce lab ne réutilise ni la VM ni les ressources d'un lab précédent.

Entrez dans le répertoire de travail et inspectez ses valeurs d'entrée préparées :

cd /home/labex/project/application-launch
cat terraform.tfvars.json

Ces valeurs identifient l'AMI, le sous-réseau et le groupe de sécurité fournis. Le réseau attribue déjà des adresses IP publiques au lancement, possède une route Internet et autorise le client User sur le port applicatif 8081. Terraform est préparé pour l'environnement du cours ; aucun identifiant personnel n'est nécessaire.

Trouvez l'image d'application fournie au moyen d'une requête AWS indépendante. Une AMI décrit l'image utilisée lors de la création d'une instance ; lire une AMI existante ne crée pas de nouvelle image.

aws ec2 \
  describe-images \
  --filters Name=name,Values=report-server-ubuntu-2204 \
  --query 'Images[].{Image:ImageId,Name:Name,Architecture:Architecture}'

Son nom est report-server-ubuntu-2204, son architecture est x86_64 et son identifiant correspond à l'entrée ami_id. Une source de données Terraform lit un objet existant ; une ressource gère le cycle de vie d'un objet. Vous lirez cette AMI avec data.aws_ami.application, puis créerez une instance avec aws_instance.application.

Créez application.tf. Le heredoc externe avec délimiteur entre guillemets écrit le HCL sans expansion du shell. Dans le HCL, ${...} interpole une expression Terraform et jsonencode convertit le message en JSON valide. Le heredoc interne CONFIG, également avec délimiteur entre guillemets, écrit ce JSON dans la configuration de l'application préparée lorsque User Data s'exécute dans la nouvelle machine invitée.

cat > application.tf <<'HCL'
data "aws_ami" "application" {
  most_recent = true
  filter {
    name   = "image-id"
    values = [var.ami_id]
  }
}

resource "aws_instance" "application" {
  ami                    = data.aws_ami.application.id
  instance_type          = "t3.micro"
  key_name               = "report-key"
  subnet_id              = var.subnet_id
  vpc_security_group_ids = [var.security_group_id]

  user_data_replace_on_change = true
  user_data = <<-SCRIPT
    #!/bin/bash
    set -eu
    cat > /etc/report-app/config.json <<'CONFIG'
    ${jsonencode({ message = var.message })}
    CONFIG
  SCRIPT

  tags = {
    Name = "application-server"
  }
}

output "instance_id" {
  value = aws_instance.application.id
}

output "image_id" {
  value = data.aws_ami.application.id
}
HCL

L'instance référence la source de données AMI plutôt qu'un identifiant d'image copié. Les entrées de sous-réseau et de groupe fournies la relient au réseau préparé. User Data s'exécute pendant le démarrage initial pour configurer l'application ; il ne s'agit pas d'une commande de connexion interactive. La valeur par défaut de l'entrée message est Terraform report application. user_data_replace_on_change fait des modifications ultérieures de la configuration de démarrage des remplacements explicites ; vous étudierez ce comportement de mise en production dans un lab ultérieur.

Initialisez, formatez et validez :

terraform init
terraform fmt
terraform validate

Si init indique 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 le plan. Il lit l'AMI fournie et propose de créer une instance EC2. Il ne doit ni remplacer le serveur de référence ni créer une nouvelle AMI.

terraform plan

Appliquez et saisissez yes à la demande de confirmation :

terraform apply

Enregistrez et affichez les identifiants d'instance et d'image obtenus :

INSTANCE_ID=$(terraform output -raw instance_id)
echo "$INSTANCE_ID"
IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"

Interrogez l'instance indépendamment. Comparez son état d'exécution, son image, son sous-réseau et son groupe de sécurité avec les entrées préparées.

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId,Subnet:SubnetId,Groups:SecurityGroups[].GroupId,PublicIP:PublicIpAddress}'

Dans AWS View, sélectionnez application-server, User · 198.51.100.10 et Application · 8081, puis cliquez sur Send request. Les résultats attendus sont Connected · 200 et Terraform report application. La réponse réelle de l'application démontre que la configuration de démarrage a atteint la charge de travail ; running seul ne permettrait pas d'établir ce résultat.

Exemple de point de contrôle : AWS View affiche l'application en cours d'exécution et son message réellement initialisé. Les identifiants de ressources et les adresses varient dans chaque VM.

Inspectez la correspondance Terraform et confirmez la convergence :

terraform state list
terraform plan

L'état contient la source de données AMI et la ressource d'instance ; le plan indique No changes.

Supprimer l'instance et conserver l'infrastructure fournie

Dans cette étape, vous allez détruire uniquement l'instance d'application gérée par Terraform tout en préservant son image source, le réseau préparé et l'application de référence.

Une source de données ne possède pas l'image qu'elle lit. Le VPC, le sous-réseau, la route, le groupe de sécurité et la paire de clés ont aussi été fournis en dehors de cet état. Examinez le périmètre de suppression avant de l'approuver :

terraform plan -destroy

Une instance gérée doit être à détruire. Lancez ensuite la suppression et saisissez yes :

terraform destroy

Interrogez le même identifiant d'instance. Son état doit être terminated ; une requête qui échoue ne prouve pas la terminaison.

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'

L'image préparée doit toujours exister avec son identifiant d'origine :

aws ec2 \
  describe-images \
  --image-ids "$IMAGE_ID" \
  --query 'Images[].{Image:ImageId,Name:Name}'

Vérifiez l'état restant :

terraform state list

Aucune ressource d'application gérée ne doit subsister. Dans AWS View, l'instance terminée n'est plus une cible en cours d'exécution sélectionnable. Sélectionnez reference-server, la source User et le port 8081, puis envoyez une requête. Sa réponse doit toujours être Connected · 200 avec Reference application.

Conservez les fichiers HCL pour examen. La configuration conservée proposerait une nouvelle instance lors d'un plan ordinaire ultérieur ; cela ne signifie pas que l'opération de destruction a échoué.

Résumé

Vous avez distingué une source de données AMI d'une ressource EC2, relié les entrées réseau fournies, initialisé une application au moyen de User Data et vérifié sa réponse réelle. Vous avez confirmé un plan sans modification et supprimé uniquement l'instance gérée, en préservant l'image, le réseau et l'application de référence.