Lanza una aplicación con inicialización automática

Introducción

Una instancia en ejecución solo resulta útil cuando su aplicación se ha inicializado correctamente. Usarás Terraform para leer una AMI de aplicación preparada, lanzar una instancia EC2 en la red suministrada y configurar la aplicación mediante User Data.

Debes conocer las variables y las referencias a recursos de Terraform, el enrutamiento de subredes públicas, los grupos de seguridad y los fundamentos del lanzamiento de instancias EC2. Este entorno nuevo proporciona la AMI, el par de claves, la red y una aplicación de referencia independiente. Crearás y eliminarás tu propia instancia de aplicación.

Relación con las certificaciones

Vista general del laboratorio

Lee una AMI y lanza la aplicación

En este paso, conectarás una AMI preparada, las entradas de red y User Data con un recurso EC2 de Terraform y, después, comprobarás la respuesta de la aplicación inicializada.

Abre Terminal y AWS View. El servidor de referencia ya está en ejecución. La red de la aplicación está preparada, pero todavía no existe application-server. Este laboratorio no reutiliza la VM ni los recursos de un laboratorio anterior.

Entra en el directorio de trabajo e inspecciona sus valores de entrada preparados:

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

Estos valores identifican la AMI, la subred y el grupo de seguridad suministrados. La red ya asigna IP públicas al lanzar instancias, tiene una ruta a Internet y permite al cliente User acceder al puerto 8081 de la aplicación. Terraform está preparado para el entorno del curso; no se necesitan credenciales personales.

Localiza la imagen de aplicación suministrada mediante una consulta independiente a AWS. Una AMI describe la imagen utilizada al crear una instancia; leer una AMI existente no crea una imagen nueva.

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

El nombre es report-server-ubuntu-2204, su arquitectura es x86_64 y su ID coincide con la entrada ami_id. Una fuente de datos de Terraform lee un objeto existente; un recurso gestiona el ciclo de vida de un objeto. Leerás esta AMI con data.aws_ami.application y crearás una instancia con aws_instance.application.

Crea application.tf. El heredoc exterior entre comillas escribe HCL sin expansión del shell. Dentro del HCL, ${...} interpola una expresión de Terraform y jsonencode convierte el mensaje en JSON válido. El heredoc interior CONFIG, también entre comillas, escribe ese JSON en la configuración de la aplicación preparada cuando User Data se ejecuta en la nueva instancia.

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

La instancia hace referencia a la fuente de datos de la AMI en lugar de a un ID de imagen copiado. Las entradas de subred y grupo suministradas la conectan con la red preparada. User Data se ejecuta durante el arranque inicial para configurar la aplicación; no es un comando de inicio de sesión interactivo. El valor predeterminado de la entrada message es Terraform report application. user_data_replace_on_change hace que los cambios posteriores en la configuración de arranque impliquen sustituciones explícitas; explorarás ese comportamiento de publicación en un laboratorio posterior.

Inicializa, da formato y valida:

terraform init
terraform fmt
terraform validate

Si init muestra Incomplete lock file information for providers, se refiere a las sumas de comprobación para otras plataformas. Esta VM preparada usa linux_amd64; continúa cuando la inicialización y la validación terminen correctamente.

Revisa el plan. Lee la AMI suministrada y propone crear una instancia EC2. No debe sustituir el servidor de referencia ni crear una AMI nueva.

terraform plan

Aplica los cambios e introduce yes cuando se solicite:

terraform apply

Guarda y muestra los ID resultantes de la instancia y la imagen:

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

Consulta la instancia de forma independiente. Comprueba su estado de ejecución, imagen, subred y grupo de seguridad frente a las entradas preparadas.

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}'

En AWS View, selecciona application-server, User · 198.51.100.10 y Application · 8081 y haz clic en Send request. Debes ver Connected · 200 y Terraform report application. La respuesta real de la aplicación demuestra que la configuración de arranque llegó a la carga de trabajo; running por sí solo no demostraría ese resultado.

Ejemplo de punto de comprobación: AWS View muestra la aplicación en ejecución y su mensaje real tras la inicialización. Los ID y las direcciones de los recursos varían en cada VM.

Inspecciona la correspondencia de Terraform y confirma la convergencia:

terraform state list
terraform plan

El estado contiene la fuente de datos de la AMI y el recurso de instancia; el plan indica No changes.

Elimina la instancia y conserva la infraestructura suministrada

En este paso, destruirás únicamente la instancia de aplicación gestionada por Terraform, conservando su imagen de origen, la red preparada y la aplicación de referencia.

Una fuente de datos no es propietaria de la imagen que lee. La VPC, la subred, la ruta, el grupo de seguridad y el par de claves también se suministraron fuera de este estado. Revisa el alcance de la eliminación antes de aprobarla:

terraform plan -destroy

Debe destruirse una instancia gestionada. Después, ejecuta la eliminación e introduce yes:

terraform destroy

Consulta el mismo ID de instancia. Su estado debe ser terminated; una solicitud fallida no demuestra que haya terminado.

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

La imagen preparada debe seguir existiendo con su ID original:

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

Comprueba el estado restante:

terraform state list

No debe quedar ningún recurso de aplicación gestionado. En AWS View, la instancia terminada ya no se puede seleccionar como destino en ejecución. Selecciona reference-server, el origen User y el puerto 8081 y envía una solicitud. Su respuesta debe seguir siendo Connected · 200 con Reference application.

Conserva los archivos HCL para revisarlos. La configuración conservada propondría una instancia nueva en un plan ordinario posterior; no significa que la operación de destrucción haya fallado.

Resumen

Has distinguido una fuente de datos de AMI de un recurso EC2, conectado las entradas de red suministradas, inicializado una aplicación mediante User Data y verificado su respuesta real. Has confirmado un plan sin cambios y eliminado únicamente la instancia gestionada, conservando la imagen, la red y la aplicación de referencia.