Создает новые экземпляры Aws::AutoScalingGroup до того, как старые будут уничтожены. (Происходит ошибка 503)

TL;DR: см. Редактирование внизу.

Я пытаюсь настроить непрерывное развертывание для нашей новой среды, в которую мы переходим в моей компании.

Я использую стек облачной информации aws для хранения всей моей инфраструктуры. Когда я создаю стек, мои экземпляры правильно инициализируются через их AWS::AutoScaling::LaunchConfiguration настройка и конкретно - AWS::CloudFormation::Init, (Это в моем JSON-шаблоне облачной информации). Этот сценарий config/init запускает контейнер моего приложения и запускает его на экземплярах ec2 в моем AWS::AutoScaling::AutoScalingGroup,

Когда я совершаю репо, у меня есть .travis-ci.yml настройка файла для запуска aws update-stack команда. Это позволит сделать так, чтобы на всех новых экземплярах, которые вносятся в мой стек, при запуске сценария инициализации запускалась новейшая версия моего докера.

Как сделать недействительными мои текущие экземпляры стека и ввести новые экземпляры стека с нулевым временем простоя?

Прямо сейчас, как указано в моем вопросе, я получаю ошибку 503. Это происходит в период времени, когда мои старые экземпляры становятся недействительными, а мои новые экземпляры "прогреваются".

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

Вот что я делаю в настоящее время, чтобы столкнуться с этой проблемой:

aws cloudformation update-stack \
    --stack-name <stack-name> \
    --template-body file://<template-file>.json \
    --profile <my-profile> \
    --parameters <params>

Тогда либо:

# This rans for each INSTANCE_ID in the current stack.
aws autoscaling set-instance-health \
    --profile <my-profile> \
    --instance-id ${INSTANCE_ID} \
    --health-status Unhealthy \
    --no-should-respect-grace-period

Или же:

aws autoscaling detach-instances \
    --auto-scaling-group-name <auto-scaling-group-name> \
    --no-should-decrement-desired-capacity \
    --profile <my-profile> \
    --instance-ids <instance-1> <instance-2>

Любая идея о том, как я могу устранить простои при замене экземпляров групп автомасштабирования, будет принята с благодарностью!

Я также был бы открыт для создания экземпляров и последующего добавления их в группу автомасштабирования через attach-instances команда. Однако я не знаю, как обеспечить эти экземпляры с уже существующими AWS::AutoScaling::LaunchConfiguration и я хочу сохранить мой процесс СУХИМ и не повторять эту функцию дважды.

Спасибо за помощь!


РЕДАКТИРОВАТЬ:

Я нашел прямое решение для замены экземпляров EC2 в моей группе автоматического масштабирования. Непосредственно из документации aws:

Политики AutoScalingReplacingUpdate и AutoScalingRollingUpdate применяются только при выполнении одного или нескольких из следующих действий:

  • Измените AWS::AutoScaling::LaunchConfiguration группы автоматического масштабирования.
  • Изменить свойство VPCZoneIdentifier группы автоматического масштабирования
  • Изменить свойство LaunchTemplate группы Auto Scaling
  • Обновите группу автоматического масштабирования, содержащую экземпляры, которые не соответствуют текущей LaunchConfiguration.

Я понял, что самым простым решением для меня было изменить имя группы автоматического масштабирования на что-то похожее на следующее:

"WebServerGroup":{
    "Type":"AWS::AutoScaling::AutoScalingGroup",
    "Properties":{
        "AutoScalingGroupName": { 
            "Fn::Sub" : "MyWebServerGroup-${UniqueDockerTag}" 
        }, 
        ...
    },
    "UpdatePolicy":{
        "AutoScalingRollingUpdate":{
            "MaxBatchSize":"50",
            "MinSuccessfulInstancesPercent": 100,
            "PauseTime": "PT5M",
            "WaitOnResourceSignals": true
        },
        "AutoScalingReplacingUpdate" : {
            "WillReplace" : "true"
        }

     }
}

${UniqueDockerTag} это параметр, передаваемый в мой шаблон, и он уникален для каждой сборки, поэтому для моего случая использования это было простое и эффективное решение.

Создается новая группа AutoScalingGroup, а после завершения создания старая группа AutoScalingGroup удаляется. Все это делается с нулевым временем простоя.

Надеюсь это поможет! Ура!

1 ответ

То, что вы пытаетесь сделать, выглядит как нечто среднее между скользящим и сине-зеленым развертыванием.

Если бы я был вами, я бы рассмотрел несколько других вариантов, прежде чем пытаться решить вашу конкретную проблему.

1. Используйте кластер ECS (или EKS)

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

ECS Cluster - это место, где вы запускаете свои контейнеры. ECS Cluster также является AutoScaling Group экземпляров EC2, но вместо того, чтобы активно извлекать образ контейнера, они присоединяются к ECS Cluster и ждут инструкций, что делать.

Вот где приходят службы ECS. Служба ECS описывает, что вы хотите запустить, т.е. определение вашего контейнера, параметры и т. Д. Затем она планирует контейнеры (задачи ECS) на доступных узлах кластера ECS.

Развертывание новой версии вашего приложения так же просто, как обновление определения службы ECS, - это можно сделать в виде непрерывного обновления, все-в-одном и т. Д. Оно легко интегрируется с ALB, ELB и т. Д., И вы, безусловно, можете достичь нуля. простои релизы.

Использование ECS устраняет необходимость замены экземпляров EC2 при каждом выпуске контейнера и заменяет только фактические контейнеры.

2. Правильное сине-зеленое размещение

Другим вариантом является правильное сине-зеленое развертывание, когда вы создаете совершенно новую среду, а затем переключаете трафик обычно на уровне DNS.

Это означает, что ваш шаблон CloudFormation для каждого выпуска будет содержать полную инфраструктуру (ASG, LaunchConfig, ALB, ...), и вы получите два экземпляра стека - например, app-blue и app-green. Когда Blue активен, вы можете разрушить и повторно развернуть Green. Проверьте это, и когда-нибудь с радостью переключите DNS с Blue ALB на Green ALB. В следующем выпуске вы повторите то же самое для Blue.

Опять же, преимущество этого в том, что у вас есть простой путь отката (просто переключите DNS обратно на Blue ALB, если развертывание Green окажется неработоспособным), и снова это позволяет без простоев.


Обновление: только что анонсировано на AWS re: Invent 2018 - поддержка развертывания Blue/Green для ECS. Эта новая функциональность может упростить ваши выпуски Службы ECS без необходимости каждый раз создавать полную среду.


Надеюсь, это поможет:)

Другие вопросы по тегам