Поддержание мощности приложения с EC2 Auto Scaling

Введение

Балансировщик может обходить неисправное приложение, но сам не создаёт замену серверу. Вы создадите шаблон и группу для двух экземпляров, вызовете сбой и проверите, что новый ID действительно обслуживает запросы.

Нужны знания EC2 User Data, целевых групп ALB и проверок приложения. Новая среда предоставляет сеть, образ, пару ключей и пустую целевую группу с HTTP-слушателем, без готового парка серверов. CLI и файлы подключения подготовлены независимо от предыдущих работ.

Связь с сертификацией

Работа даёт начальную практику по следующим темам.

Solutions Architect – Associate (SAA-C03) · Задача 2.1: Шаблоны, мощность группы и интеграция балансировщика; задача 2.2: Замена неисправных backend для доступности.
CloudOps Engineer – Associate (SOA-C03) · Задача 2.1: Поддержание мощности EC2; задача 2.2: Выявление и замена backend по состоянию приложения.

Создание шаблона запуска приложения

Определите настройки, с которыми Auto Scaling запускает каждый сервер.

Перейдите в рабочую папку и загрузите подготовленные сетевые переменные:

cd /home/labex/project
source launch.env

Шаблон запуска хранит AMI, тип, группы безопасности и начальные настройки. Изучите предоставленный файл:

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

JSON выбирает подготовленный AMI, t3.micro, report-key и группу безопасности приложения. UserData содержит отдельно показанный скрипт в base64. Скрипт задаёт сообщение Application ready и healthy равным true. Эти настройки нужны при каждом запуске; изменение внутри старого сервера не меняет шаблон.

Создайте шаблон. file:// указывает CLI прочитать значение параметра из 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)

Шаблоны имеют пронумерованные версии. Проверьте версию 1, которую группа использует явно:

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

Создание шаблона не запускает экземпляры. Откройте AWS View: ALB и целевая группа существуют, но приложения ещё не зарегистрированы.

Запуск и подключение группы серверов

Создайте группу Auto Scaling и подключите реальные экземпляры к подготовленному ALB.

Группа Auto Scaling поддерживает нужное количество между минимумом и максимумом. Желаемая мощность — количество экземпляров, а не измерение пропускной способности. Минимум 2, желаемое 2, максимум 3 позволяют начать с двух серверов и добавить один.

Получите ARN целевой группы и DNS-имя балансировщика:

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)

Создайте группу с версией 1 и обеими подсетями. --target-group-arns автоматически регистрирует экземпляры в ALB. --health-check-type ELB включает состояние балансировщика в решение о замене; проверки EC2 не обнаруживают все сбои приложения. Льготный период даёт время на запуск перед заменой по состоянию приложения. Здесь это 30 секунд; в рабочей системе он должен соответствовать времени запуска:

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

Проверьте группу и её 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}'

Дождитесь готовности приложений и проверьте цели:

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

Ожидаются два исправных ID. Отправьте шесть запросов и сравните ответы с экземплярами группы:

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

В AWS View подтвердите мощность 2, две исправные цели и настоящие ответы 200 обоих IDs кнопкой Send request. Подсети и зоны показывают настройки; физическая устойчивость между зонами здесь не измеряется.

Наблюдение автоматической замены

Вызовите сбой приложения и позвольте группе заменить экземпляр без ручного ремонта.

Выберите текущий экземпляр группы и получите публичный адрес для 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)

Измените только healthy, чтобы получать 503. Как раньше, временный JSON предотвращает перезапись файла во время чтения:

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'

Ожидайте 503. Приложение отказало, пока экземпляр работает. ALB обнаруживает ошибки; после льготного периода группа заменяет экземпляр, восстанавливая мощность. Тот же шаблон запускает замену с исправными настройками.

Наблюдайте IDs и состояние в AWS View. Неисправное состояние может быть кратким, поскольку сразу следует замена. Новая цель может сначала показывать initial. Не ремонтируйте приложение и не выполняйте дополнительный run-instances.

Дождитесь завершения старого экземпляра и исправных целей:

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

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

Проверьте старый экземпляр и текущую группу:

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

Старый ID должен быть terminated. Мощность остаётся 2, появляется новый ID. Замена — заново инициализированный сервер; изменения только внутри старого автоматически не сохраняются.

Снова отправьте шесть запросов:

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

Найдите оба текущих ID, включая новый, без старого. В AWS View подтвердите две исправные цели и настоящий ответ замены через Send request. Количество ресурсов само по себе не доказывает работу приложения.

Ответ заменившего экземпляра

Пример: мощность остаётся два, новый экземпляр отвечает HTTP 200. Ваши IDs будут другими.

Удаление группы и шаблона

Удалите свою группу, экземпляры и шаблон, сохранив подготовленные ALB и сеть.

Удалите группу с --force-delete, завершив экземпляры несмотря на минимум 2. Удаление одного шаблона не останавливает работающие экземпляры:

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"

Команда ожидания выбирает экземпляры по автоматическому тегу Auto Scaling, включая старый заменённый, и ждёт завершения всех. Проверьте отсутствие группы, список шаблонов и зарегистрированных целей:

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'

Все три списка должны быть []. Снятие регистрации может занять время; подождите и повторите последний запрос. AWS View сохраняет ALB и целевую группу без серверов и зарегистрированных целей. Оставьте предоставленные сеть, AMI и пару ключей.

Итоги

Вы создали шаблон с версиями и группу для двух реальных серверов. Использовали проверки ALB, вызвали сбой и подтвердили запросы от нового ID. Затем удалили группу, экземпляры и шаблон, сохранив балансировщик и сеть.

Следующая работа меняет мощность простыми политиками масштабирования и проверяет границы группы.

Поддержание мощности с группой Auto Scaling