Manter capacidade com EC2 Auto Scaling

Introdução

Um balanceador evita aplicações com falha, mas não cria servidores substitutos. Você criará um modelo e um grupo que mantém duas instâncias, causará uma falha e verificará que um novo ID atende solicitações de verdade.

Você deve conhecer EC2 User Data, grupos de destino ALB e verificações de aplicações. Este ambiente novo fornece rede, imagem, par de chaves e grupo de destino vazio com listener HTTP, sem frota existente. CLI e arquivos de conexão são preparados independentemente dos laboratórios anteriores.

Relação com certificações

Este laboratório oferece prática introdutória dos seguintes temas.

Solutions Architect – Associate (SAA-C03) · Tarefa 2.1: Modelos, capacidade Auto Scaling e integração do balanceador; tarefa 2.2: Substituir backends com falha para apoiar disponibilidade.
CloudOps Engineer – Associate (SOA-C03) · Tarefa 2.1: Manter capacidade EC2; tarefa 2.2: Identificar e substituir backends pela integridade da aplicação.

Criar o modelo de execução

Você definirá a configuração usada pelo Auto Scaling ao iniciar cada servidor.

Entre no diretório e carregue as variáveis de rede preparadas:

cd /home/labex/project
source launch.env

Um modelo de execução guarda AMI, tipo, grupos de segurança e configuração inicial. Examine o arquivo fornecido:

cat launch-template.json
cat application-user-data.sh

O JSON seleciona a AMI preparada, t3.micro, report-key e o grupo de segurança da aplicação. UserData contém o script exibido separadamente, codificado em base64. Ele define a mensagem Application ready e healthy como true. Todo lançamento deve aplicar essa configuração; uma alteração dentro do servidor antigo não muda o modelo.

Crie o modelo. file:// instrui a CLI a ler o valor do parâmetro do JSON:

LT_ID=$(aws ec2 \
  create-launch-template \
  --launch-template-name application-template \
  --launch-template-data file://launch-template.json \
  --query 'LaunchTemplate.LaunchTemplateId' \
  --output text)

Modelos possuem versões numeradas. Examine a versão 1, usada explicitamente pelo grupo:

aws ec2 \
  describe-launch-template-versions \
  --launch-template-id "$LT_ID" \
  --versions 1 \
  --query 'LaunchTemplateVersions[].{Version:VersionNumber,AMI:LaunchTemplateData.ImageId,Type:LaunchTemplateData.InstanceType,Key:LaunchTemplateData.KeyName,Groups:LaunchTemplateData.SecurityGroupIds}'

Criar um modelo não inicia instâncias. Abra AWS View: ALB e grupo de destino existem, mas ainda não há aplicações registradas.

Iniciar e conectar a frota

Você criará um grupo Auto Scaling e conectará suas instâncias reais ao ALB fornecido.

Um grupo Auto Scaling mantém a quantidade desejada entre mínimo e máximo. A capacidade desejada é um número de instâncias, não uma medida de throughput. Mínimo 2, desejado 2 e máximo 3 iniciam dois servidores e permitem adicionar mais um.

Obtenha o ARN do grupo de destino e o nome DNS do balanceador:

TG_ARN=$(aws elbv2 \
  describe-target-groups \
  --names application-targets \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

LB_DNS=$(aws elbv2 \
  describe-load-balancers \
  --names application-alb \
  --query 'LoadBalancers[0].DNSName' \
  --output text)

Crie o grupo com versão 1 e ambas as sub-redes. --target-group-arns registra automaticamente as instâncias no ALB. --health-check-type ELB inclui a integridade do balanceador nas decisões de substituição; verificações EC2 não identificam todas as falhas da aplicação. O período de carência permite iniciar antes de substituir por falha. Aqui usamos 30 segundos; em produção, ajuste ao tempo de inicialização:

aws autoscaling \
  create-auto-scaling-group \
  --auto-scaling-group-name application-fleet \
  --launch-template "LaunchTemplateId=$LT_ID,Version=1" \
  --min-size 2 \
  --max-size 3 \
  --desired-capacity 2 \
  --vpc-zone-identifier "$SUBNET_ID,$SECOND_SUBNET_ID" \
  --target-group-arns "$TG_ARN" \
  --health-check-type ELB \
  --health-check-grace-period 30

Examine o grupo e seus IDs:

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,HealthCheck:HealthCheckType,Grace:HealthCheckGracePeriod,Instances:Instances[].InstanceId}'

Aguarde as aplicações ficarem prontas e examine os destinos:

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

aws elbv2 \
  describe-target-health \
  --target-group-arn "$TG_ARN" \
  --query 'TargetHealthDescriptions[].{Instance:Target.Id,Health:TargetHealth.State}' \
  --output table

Espere dois IDs íntegros. Envie seis solicitações e compare respostas com as instâncias do grupo:

for request in 1 2 3 4 5 6; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

Abra AWS View. Confirme capacidade 2, dois destinos íntegros e respostas reais 200 de ambos os IDs com Send request. Sub-redes e zonas indicam configuração; o exercício não mede resiliência física entre zonas.

Observar a substituição automática

Você causará uma falha e deixará o grupo substituir a instância sem repará-la manualmente.

Escolha uma instância atual e obtenha o endereço público para SSH:

OLD_ID=$(aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[0].Instances[0].InstanceId' \
  --output text)

OLD_IP=$(aws ec2 \
  describe-instances \
  --instance-ids "$OLD_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

Altere somente healthy para retornar 503. Como antes, um JSON temporário evita sobrescrever o arquivo enquanto ele é lido:

ssh -F ssh_config "ubuntu@$OLD_IP" \
  'sudo jq ".healthy = false" /etc/report-app/config.json > /tmp/report-config.json && sudo install -m 644 /tmp/report-config.json /etc/report-app/config.json'

ssh -F ssh_config "ubuntu@$OLD_IP" \
  'curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8081/health'

Espere 503. A aplicação falhou enquanto a instância continuava executando. ALB detecta as falhas; após a carência, o grupo substitui a instância para restaurar a capacidade. O mesmo modelo inicia o substituto com configuração íntegra.

Mantenha AWS View aberto para observar IDs e estados. O estado não íntegro pode ser breve porque a substituição segue a detecção. Um novo destino pode começar como initial. Não faça reparos nem execute outro run-instances.

Aguarde a terminação da instância antiga e a integridade do grupo de destino:

aws ec2 \
  wait instance-terminated \
  --instance-ids "$OLD_ID"

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

Examine a instância antiga e o grupo atual:

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

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Desired:DesiredCapacity,Instances:Instances[].InstanceId}'

O ID antigo deve estar terminated. A capacidade permanece 2, com novo ID no lugar do antigo. O substituto é inicializado novamente; mudanças internas do servidor antigo não são preservadas automaticamente.

Envie novamente seis solicitações:

for request in 1 2 3 4 5 6; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

Procure os dois IDs atuais, incluindo o substituto, sem o antigo. Em AWS View, confirme destinos íntegros e use Send request para observar o novo servidor responder. Contar recursos não comprova funcionamento da aplicação.

Instância substituta respondendo

Exemplo: a capacidade continua em dois e a nova instância retorna HTTP 200. Seus IDs serão diferentes.

Excluir a frota e o modelo

Você removerá grupo, instâncias e modelo, preservando ALB e rede fornecidos.

Exclua o grupo com --force-delete para terminar instâncias mesmo com mínimo 2. Excluir somente o modelo não interrompe instâncias:

aws autoscaling \
  delete-auto-scaling-group \
  --auto-scaling-group-name application-fleet \
  --force-delete

aws ec2 \
  wait instance-terminated \
  --filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet"

aws ec2 \
  delete-launch-template \
  --launch-template-id "$LT_ID"

O waiter seleciona as instâncias pela tag automática do Auto Scaling, incluindo a instância substituída, e aguarda todas terminarem. Verifique ausência do grupo, modelos e registros de destinos:

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].AutoScalingGroupName'

aws ec2 \
  describe-launch-templates \
  --query 'LaunchTemplates[].LaunchTemplateName'

aws elbv2 \
  describe-target-health \
  --target-group-arn "$TG_ARN" \
  --query 'TargetHealthDescriptions[].Target.Id'

As três listas devem ser []. O cancelamento do registro pode demorar; aguarde e repita a última consulta se necessário. AWS View mantém ALB e grupo de destino sem frota nem destinos registrados. Preserve rede, AMI e par de chaves.

Resumo

Você criou um modelo com versões e um grupo para dois servidores reais. Incluiu verificações ALB, causou uma falha e verificou solicitações de um novo ID. Depois removeu grupo, instâncias e modelo, preservando balanceador e rede.

O próximo laboratório altera a capacidade com políticas simples e testa os limites do grupo.

Manter capacidade com um grupo Auto Scaling