Define una red para una aplicación

Introducción

Tu aplicación necesita un espacio de direcciones antes de poder ejecutarse. Definirás una VPC de AWS y una subred con Terraform, compararás la red desplegada con el estado de Terraform y eliminarás únicamente la red de tu aplicación.

Ya debes conocer el flujo init/plan/apply de Terraform, las direcciones de recursos y los conceptos básicos de CIDR para VPC y subredes de AWS. Terminal, las herramientas de Terraform, la AWS CLI y una red de referencia independiente ya están preparados. Cada laboratorio comienza de forma independiente; no necesitas recursos de una VM anterior.

Relación con las certificaciones

Vista general del laboratorio

Define y despliega la VPC

En este paso, plasmarás el plan de direccionamiento de la aplicación en un recurso de Terraform e inspeccionarás la VPC resultante.

Abre Terminal. AWS View muestra los recursos de red actuales; úsalo para observar la topología, mientras la CLI proporciona campos precisos y Terraform gestiona los cambios. La red existente reference-network pertenece a otra aplicación y debe permanecer sin cambios.

Una VPC es un límite de red regional. Su bloque CIDR define su rango de direcciones: 10.62.0.0/16 reserva direcciones para esta aplicación. En Terraform, aws_vpc.application es una dirección de configuración, no un ID de AWS. AWS asigna el ID después de la creación.

El directorio application-network contiene la configuración preparada del proveedor. Selecciona la cuenta suministrada y las versiones de las herramientas que se han probado. Entra en este directorio:

cd /home/labex/project/application-network

Crea main.tf. El heredoc entre comillas escribe literalmente el siguiente HCL hasta HCL; > crea o sustituye este archivo. La etiqueta Name permite distinguir fácilmente la red de la aplicación de la red de referencia.

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

Inicializa el directorio de trabajo para seleccionar el proveedor necesario y, después, da formato a la configuración y valídala. La validación comprueba la estructura de la configuración; no demuestra que exista un recurso.

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 un plan. Terraform también describe los ajustes predeterminados de la VPC; localiza cidr_block y la etiqueta Name en la creación propuesta.

terraform plan

El resumen final debe mostrar un recurso para añadir. Aplica la configuración e introduce yes cuando Terraform solicite confirmación:

terraform apply

Consulta la VPC que se ha creado. --filters selecciona la etiqueta de la aplicación; --query muestra únicamente el ID y el CIDR. El ID varía, mientras que el CIDR debe ser 10.62.0.0/16.

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

Vuelve a observar AWS View: la VPC de la aplicación aparece junto a la VPC de referencia. La nueva VPC aún no tiene ninguna subred de la aplicación.

Conecta una subred mediante una referencia a un recurso

En este paso, crearás una subred dentro de la VPC de la aplicación y comprobarás su rango de direcciones, su zona de disponibilidad y su correspondencia en Terraform.

Una subred pertenece exactamente a una VPC y a una zona de disponibilidad. Usa 10.62.1.0/24, un rango más pequeño dentro del /16 de la VPC, en us-east-1a. Ni este CIDR ni una zona de disponibilidad convierten por sí solos una subred en pública; el enrutamiento a Internet y las reglas de acceso se tratarán más adelante.

Crea subnet.tf. La expresión aws_vpc.application.id hace referencia al recurso de la VPC. Terraform usa esa dependencia para crear la VPC antes que la subred y obtiene el ID real automáticamente. No tienes que copiar un ID de la salida de un comando al 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

Da formato al archivo nuevo, valídalo y revisa el plan. Debe añadir una subred y exponer dos valores de salida, sin sustituir tu VPC.

terraform fmt
terraform validate
terraform plan

Aplica los cambios y confirma con yes:

terraform apply

Guarda y muestra los ID generados. $(...) captura la salida de un comando; terraform output -raw devuelve una cadena sin comillas.

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

Consulta AWS de forma independiente. El campo VPC de la subred debe coincidir con el ID de VPC mostrado, su CIDR debe ser 10.62.1.0/24 y su zona de disponibilidad debe ser us-east-1a.

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

El estado de Terraform asocia las direcciones de configuración con los recursos desplegados. Inspecciona esa correspondencia; compara los ID de la VPC y de la subred con AWS, en lugar de considerar una entrada en el estado como prueba de que la red funciona.

terraform state list
terraform state show aws_subnet.application

La lista incluye aws_vpc.application y aws_subnet.application. Ahora comprueba la convergencia:

terraform plan

Debes ver No changes. En AWS View, la subred de la aplicación aparece dentro de la VPC a la que pertenece, junto a la red de referencia que permanece intacta.

Elimina únicamente la red de la aplicación

En este paso, revisarás el orden de eliminación, destruirás tu conjunto de recursos de Terraform y confirmarás que se conserva la red de referencia.

Terraform usa el mismo grafo de dependencias en sentido inverso: elimina la subred antes que la VPC. Un plan de eliminación abarca los recursos gestionados por este directorio de trabajo, por lo que la red de referencia preparada de forma independiente no debe aparecer.

Revisa las eliminaciones previstas:

terraform plan -destroy

Debes ver dos recursos para eliminar. Comprueba las direcciones de los recursos antes de continuar. Después, elimina la red de la aplicación e introduce yes:

terraform destroy

Consulta los recursos de la aplicación por etiqueta. Ambas consultas deben devolver listas vacías; una solicitud fallida no demuestra la eliminación.

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'

Confirma que Terraform ya no gestiona ningún recurso:

terraform state list

El comando no muestra ninguna dirección de recurso. Por último, inspecciona la subred de referencia que se ha conservado:

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

Su CIDR sigue siendo 10.90.1.0/24 en us-east-1b. AWS View ahora muestra solo la red de referencia. Tus archivos HCL siguen disponibles para revisarlos, aunque los recursos de la aplicación se hayan eliminado.

Resumen

Has definido una VPC y una subred en HCL, usado una referencia a un recurso para conectarlas, comparado los campos de red actuales de AWS con el estado de Terraform y confirmado un plan sin cambios. Después, has eliminado únicamente tu red gestionada y conservado una red de referencia ajena. El enrutamiento y las reglas de seguridad son pasos independientes para conseguir que una aplicación sea accesible.