Introducción
Tu equipo tiene dos servidores de aplicaciones, pero los clientes necesitan una dirección única para el servicio. Crearás un Application Load Balancer, conectarás su listener a un grupo de destino y registrarás ambos servidores. Las respuestas HTTP reales indicarán qué servidor atendió cada solicitud.
Debes conocer las instancias EC2, las subredes VPC y los grupos de seguridad de los cursos anteriores. El entorno proporciona la red, los servidores en ejecución y AWS CLI configurado. Crearás los recursos de balanceo y los eliminarás al finalizar.
Relación con certificaciones
Este laboratorio ofrece práctica introductoria para estos temas de examen.
- Solutions Architect – Associate (SAA-C03) · Tarea 2.1: Conceptos de Application Load Balancer y distribución de solicitudes entre servidores de aplicaciones.
- CloudOps Engineer – Associate (SOA-C03) · Tarea 2.2: Configuración básica de Elastic Load Balancing y observación de la disponibilidad de los destinos.
Crea el Application Load Balancer
En este paso crearás un punto de entrada único para los dos servidores preparados.
Un Application Load Balancer (ALB) distribuye solicitudes HTTP o HTTPS a servidores de aplicaciones. Un Network Load Balancer (NLB) se centra en conexiones de transporte como TCP y UDP; ALB es adecuado para esta aplicación HTTP. Usarás ALB durante todo el laboratorio.
Entra en el directorio de trabajo preparado:
cd /home/labex/project
El archivo launch.env contiene los identificadores de la red proporcionada. Léelo y usa source para cargar sus asignaciones de variables en el shell actual:
cat launch.env
source launch.env
SUBNET_ID y SECOND_SUBNET_ID identifican subredes de dos zonas de disponibilidad diferentes. ALB requiere al menos dos subredes de este tipo. ALB_SECURITY_GROUP_ID identifica el grupo preparado que permite tráfico HTTP en el puerto 80; los servidores usan otro grupo para su puerto de aplicación.
Crea un balanceador de aplicaciones orientado a Internet llamado application-alb. Orientado a Internet describe su esquema de direccionamiento. --query selecciona solo el ARN y --output text facilita reutilizarlo. La sintaxis $(...) del shell guarda la salida en LB_ARN:
LB_ARN=$(aws elbv2 \
create-load-balancer \
--name application-alb \
--type application \
--scheme internet-facing \
--subnets "$SUBNET_ID" "$SECOND_SUBNET_ID" \
--security-groups "$ALB_SECURITY_GROUP_ID" \
--query 'LoadBalancers[0].LoadBalancerArn' \
--output text)
Un Amazon Resource Name (ARN) identifica un recurso AWS. Inspecciona el balanceador con el ARN que acabas de guardar:
aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,Scheme:Scheme,DNS:DNSName}'
Busca application-alb, tipo application y esquema internet-facing. El nombre DNS será la dirección de los clientes y puede variar entre entornos. Crear el balanceador todavía no conecta los servidores.
Haz clic en AWS View, junto a Terminal. La página lee el mismo estado que CLI y debe mostrar application-alb. Las áreas de grupo de destino y destinos siguen vacías porque aún no los has conectado.
La imagen muestra este punto de creación. El nombre coincide con el laboratorio; el DNS es un valor de ejemplo.
Conecta un listener a un grupo de destino
En este paso definirás adónde van las solicitudes HTTP entrantes.
Un grupo de destino contiene los servidores que pueden atender una aplicación. Su puerto se usa para contactar esos servidores. Un listener acepta conexiones de clientes en el balanceador y usa una acción para decidir el destino. Aquí los clientes usan el puerto 80 y la aplicación de los servidores usa 8081.
Crea un grupo de destino de instancias en la VPC proporcionada. --target-type instance indica que registrarás IDs de EC2. La ruta /health es el endpoint de disponibilidad de la aplicación:
TG_ARN=$(aws elbv2 \
create-target-group \
--name application-targets \
--protocol HTTP \
--port 8081 \
--vpc-id "$VPC_ID" \
--target-type instance \
--health-check-path /health \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
Crea el listener HTTP. Su acción predeterminada reenvía solicitudes a TG_ARN. La abreviatura CLI Type=forward,TargetGroupArn=... especifica esa acción:
LISTENER_ARN=$(aws elbv2 \
create-listener \
--load-balancer-arn "$LB_ARN" \
--protocol HTTP \
--port 80 \
--default-actions "Type=forward,TargetGroupArn=$TG_ARN" \
--query 'Listeners[0].ListenerArn' \
--output text)
Inspecciona el listener resultante:
aws elbv2 \
describe-listeners \
--load-balancer-arn "$LB_ARN" \
--query 'Listeners[].{Protocol:Protocol,Port:Port,Actions:DefaultActions}'
La salida debe mostrar HTTP en el puerto 80 y una acción de reenvío hacia tu grupo. En AWS View, el grupo aparece entre el ALB y los servidores. Aún no tiene destinos registrados; debes conectar los servidores.
Registra y prueba ambos servidores
En este paso registrarás dos servidores en ejecución y observarás solicitudes reales en ambos.
Lista los servidores preparados. El filtro de nombres selecciona sus etiquetas y la consulta muestra los campos de conexión útiles:
aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-a,app-b' \
--query 'Reservations[].Instances[].{Instance:InstanceId,Name:Tags[?Key==`Name`].Value|[0],State:State.Name,PrivateIP:PrivateIpAddress}' \
--output table
Ambas instancias deben estar running. Obtén sus IDs por separado según el nombre para evitar depender del orden de la lista:
APP_A=$(aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-a' \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
APP_B=$(aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-b' \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Registrar destinos conecta estos IDs al grupo. Sin una excepción explícita Port, cada destino usa el puerto 8081 del grupo:
aws elbv2 \
register-targets \
--target-group-arn "$TG_ARN" \
--targets "Id=$APP_A" "Id=$APP_B"
El ALB consulta /health para determinar la disponibilidad. Espera hasta que los destinos estén saludables. Un waiter de CLI repite consultas de solo lectura hasta cumplir la condición o agotar el tiempo:
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Inspecciona los IDs, puertos y estados de salud registrados:
aws elbv2 \
describe-target-health \
--target-group-arn "$TG_ARN" \
--query 'TargetHealthDescriptions[].{Instance:Target.Id,Port:Target.Port,Health:TargetHealth.State}' \
--output table
Ambos destinos deben mostrar puerto 8081 y estado healthy. Guarda el nombre DNS del balanceador:
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[0].DNSName' \
--output text)
Usa curl, un cliente HTTP, para consultar el endpoint de salud. --config client.conf lee los ajustes de conexión proporcionados; -sS oculta el progreso sin ocultar errores:
curl --config client.conf -sS "http://$LB_DNS/health"
Una respuesta correcta se parece a este ejemplo; el ID de instancia es ilustrativo:
{"service":"Report server","message":"Application ready","instance_id":"i-..."}
Envía seis solicitudes independientes. El bucle for repite la solicitud y echo coloca cada respuesta en una línea:
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Busca los valores de APP_A y APP_B en las respuestas. Esto demuestra distribución entre dos servidores; no deduzcas rendimiento ni capacidad a partir del número de solicitudes. El algoritmo predeterminado del grupo es round robin. En producción también influyen las conexiones y otros ajustes.
Abre AWS View y confirma que ambos destinos estén saludables. Pulsa Send request varias veces y lee instance_id. La solicitud atraviesa el listener hasta la aplicación; las tarjetas muestran recursos, mientras que la respuesta identifica el servidor que realmente la atendió.
El ejemplo muestra dos destinos saludables y una solicitud correcta. Tus IDs serán distintos; compara la respuesta con tus propios destinos.
Elimina los recursos de balanceo
En este paso eliminarás tus recursos y conservarás los servidores y la red proporcionados.
Elimina primero el listener para quitar la dependencia de reenvío al grupo:
aws elbv2 \
delete-listener \
--listener-arn "$LISTENER_ARN"
Elimina tu balanceador y después su grupo de destino:
aws elbv2 \
delete-load-balancer \
--load-balancer-arn "$LB_ARN"
aws elbv2 \
delete-target-group \
--target-group-arn "$TG_ARN"
Confirma que ambos inventarios de balanceo estén vacíos:
aws elbv2 \
describe-load-balancers \
--query 'LoadBalancers[].LoadBalancerName'
aws elbv2 \
describe-target-groups \
--query 'TargetGroups[].TargetGroupName'
Cada consulta debe devolver []. AWS View debe mostrar que no hay balanceador ni grupo. Las instancias EC2 proporcionadas siguen ejecutándose; son recursos de preparación y no forman parte de tu limpieza.
Resumen
Creaste un Application Load Balancer, conectaste un listener HTTP a un grupo y registraste dos servidores EC2. Inspeccionaste su salud e identificaste ambos servidores mediante respuestas reales. Finalmente, eliminaste tus recursos de balanceo y conservaste la red y los servidores preparados.
El siguiente laboratorio explica cómo los chequeos de salud detectan fallos, mantienen el tráfico en destinos saludables y readmiten un destino recuperado.
