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 группы Auto Scaling.
• Измените свойство VPCZoneIdentifier группы Auto Scaling
• Измените свойство LaunchTemplate группы Auto Scaling
• Обновите группу 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 удаляется. Все это делается с нулевым временем простоя.

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