Introdução
Sua equipe tem dois servidores de aplicação, mas os clientes precisam de um endereço único para o serviço. Você criará um Application Load Balancer, conectará seu listener a um grupo de destino e registrará os dois servidores. Respostas HTTP reais mostrarão qual servidor atendeu cada solicitação.
Você deve conhecer instâncias EC2, sub-redes VPC e grupos de segurança dos cursos anteriores. O ambiente fornece a rede, os servidores em execução e AWS CLI configurado. Você criará os recursos de balanceamento e os removerá ao terminar.
Relação com certificações
Este laboratório oferece prática introdutória para estes tópicos de exame.
- Solutions Architect – Associate (SAA-C03) · Tarefa 2.1: Conceitos de Application Load Balancer e distribuição de solicitações entre servidores de aplicação.
- CloudOps Engineer – Associate (SOA-C03) · Tarefa 2.2: Configuração básica de Elastic Load Balancing e observação da disponibilidade dos destinos.
Crie o Application Load Balancer
Nesta etapa, você criará um ponto de entrada único para os dois servidores preparados.
Um Application Load Balancer (ALB) distribui solicitações HTTP ou HTTPS para servidores de aplicação. Um Network Load Balancer (NLB) trabalha com conexões de transporte, como TCP e UDP; ALB é adequado para esta aplicação HTTP. Você usará ALB em todo o laboratório.
Entre no diretório de trabalho preparado:
cd /home/labex/project
O arquivo launch.env contém os identificadores da rede fornecida. Leia-o e use source para carregar as atribuições de variáveis no shell atual:
cat launch.env
source launch.env
SUBNET_ID e SECOND_SUBNET_ID identificam sub-redes em duas zonas de disponibilidade distintas. ALB exige pelo menos duas sub-redes desse tipo. ALB_SECURITY_GROUP_ID identifica o grupo preparado que permite HTTP na porta 80; os servidores têm outro grupo para sua porta de aplicação.
Crie um balanceador de aplicações voltado para a Internet chamado application-alb. Voltado para a Internet descreve seu esquema de endereçamento. --query seleciona apenas o ARN e --output text facilita sua reutilização. A sintaxe $(...) do shell salva a saída em 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)
Um Amazon Resource Name (ARN) identifica um recurso AWS. Inspecione o balanceador com o ARN salvo:
aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,Scheme:Scheme,DNS:DNSName}'
Procure application-alb, tipo application e esquema internet-facing. O nome DNS será o endereço dos clientes e varia entre ambientes. Criar apenas o balanceador ainda não conecta os servidores.
Clique em AWS View, ao lado de Terminal. A página lê o mesmo estado que CLI e deve mostrar application-alb. As áreas de grupo e destinos continuam vazias porque ainda não foram conectadas.
A imagem mostra este ponto de criação. O nome corresponde ao laboratório; o DNS é um exemplo.
Conecte um listener a um grupo de destino
Nesta etapa, você definirá para onde vão as solicitações HTTP recebidas.
Um grupo de destino contém os servidores que podem atender uma aplicação. Sua porta é usada para contactar esses servidores. Um listener recebe conexões dos clientes no balanceador e escolhe o destino por uma ação. Aqui os clientes usam a porta 80, e a aplicação dos servidores usa 8081.
Crie um grupo de destino do tipo instância na VPC fornecida. --target-type instance significa que você registrará IDs EC2. O caminho /health é o endpoint de prontidão da aplicação:
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)
Crie o listener HTTP. Sua ação padrão encaminha solicitações para TG_ARN. A forma abreviada CLI Type=forward,TargetGroupArn=... especifica essa ação:
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)
Inspecione o listener criado:
aws elbv2 \
describe-listeners \
--load-balancer-arn "$LB_ARN" \
--query 'Listeners[].{Protocol:Protocol,Port:Port,Actions:DefaultActions}'
A saída deve mostrar HTTP na porta 80 e uma ação de encaminhamento para seu grupo. Em AWS View, o grupo aparece entre ALB e servidores. Ainda não há destinos registrados; você precisa conectar os servidores.
Registre e teste ambos os servidores
Nesta etapa, você registrará dois servidores em execução e observará solicitações reais em ambos.
Liste os servidores preparados. O filtro de nomes seleciona suas tags e a consulta mostra campos úteis de conexão:
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 as instâncias devem estar running. Obtenha seus IDs separadamente por nome para não depender da ordem da 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 esses IDs ao grupo. Sem uma substituição explícita Port, cada destino usa a porta 8081 do grupo:
aws elbv2 \
register-targets \
--target-group-arn "$TG_ARN" \
--targets "Id=$APP_A" "Id=$APP_B"
O ALB consulta /health para determinar a disponibilidade. Espere até que os destinos estejam saudáveis. Um waiter CLI repete consultas somente de leitura até cumprir a condição ou atingir o limite de tempo:
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Inspecione os IDs, portas e estados de saúde 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 os destinos devem mostrar porta 8081 e estado healthy. Salve o nome DNS do balanceador:
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[0].DNSName' \
--output text)
Use curl, um cliente HTTP, para consultar o endpoint de saúde. --config client.conf lê as configurações fornecidas; -sS oculta o progresso e mantém os erros visíveis:
curl --config client.conf -sS "http://$LB_DNS/health"
Uma resposta bem-sucedida se parece com este exemplo; o ID da instância é ilustrativo:
{"service":"Report server","message":"Application ready","instance_id":"i-..."}
Envie seis solicitações separadas. O laço for repete a solicitação e echo coloca cada resposta em uma linha:
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Procure os valores de APP_A e APP_B nas respostas. Isso demonstra distribuição entre dois servidores; não deduza desempenho nem capacidade pela quantidade de solicitações. O algoritmo padrão é round robin. Em produção, conexões e outras configurações também influenciam a distribuição.
Abra AWS View e confirme que ambos os destinos estão saudáveis. Clique várias vezes em Send request e leia instance_id. A solicitação passa pelo listener até a aplicação; os cartões mostram recursos, enquanto a resposta identifica quem realmente a atendeu.
O exemplo mostra dois destinos saudáveis e uma solicitação bem-sucedida. Seus IDs serão diferentes; compare a resposta com seus próprios destinos.
Remova os recursos de balanceamento
Nesta etapa, você removerá seus recursos e preservará os servidores e a rede fornecidos.
Exclua primeiro o listener para remover a dependência de encaminhamento ao grupo:
aws elbv2 \
delete-listener \
--listener-arn "$LISTENER_ARN"
Exclua seu balanceador e depois o grupo de destino:
aws elbv2 \
delete-load-balancer \
--load-balancer-arn "$LB_ARN"
aws elbv2 \
delete-target-group \
--target-group-arn "$TG_ARN"
Confirme que ambos os inventários de balanceamento estão vazios:
aws elbv2 \
describe-load-balancers \
--query 'LoadBalancers[].LoadBalancerName'
aws elbv2 \
describe-target-groups \
--query 'TargetGroups[].TargetGroupName'
Cada consulta deve retornar []. AWS View deve mostrar que não há balanceador nem grupo. Os servidores EC2 fornecidos continuam em execução; são recursos de preparação e não fazem parte da sua limpeza.
Resumo
Você criou um Application Load Balancer, conectou um listener HTTP a um grupo e registrou dois servidores EC2. Inspecionou a saúde e identificou ambos por respostas reais. Por fim, removeu seus recursos de balanceamento e preservou a rede e os servidores preparados.
O próximo laboratório mostra como verificações de saúde detectam falhas, mantêm o tráfego nos destinos saudáveis e readmitem um destino recuperado.
