Установить тайм-аут стека обновления облачной информации ECS?

Question

При обновлении стека службы контейнеров (ECS) Cloudformation EC2 новым образом контейнера, есть ли способ контролировать время ожидания, поэтому, если служба не стабилизирует, он автоматически откатывается?

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

Я также пробовал WaitCondition, но не смог заставить его работать.

По сути, стек просто остается в состоянии UPDATE_IN_PROGRESS до тех пор, пока не истечет время ожидания по умолчанию (~3 часа), или вы не вызовете отмену обновления.

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

Вот как выглядит мой шаблон Cloudformation: https://s3.amazonaws.com/aws-rga-cw-public/ops/cfn/ecs-cluster-asg-elb-cfn.yaml
Благодарю.

Answer 1

Мой способ решения этой проблемы заключается в том, что перед запуском стека обновлений запустите сценарий в фоновом режиме.

      ./deployment-breaker.sh &

А для сценария

      #!/bin/bash
sleep 600
$deploymentStatus = (aws cloudformation describe-stack --stack-name STACK_NAME | jq XXX)
if [[ $deploymentStatus == YOUR_TERMINATE_CONDITION ]]then
  aws cloudformation cancel-update-stack --stack-name STACK_NAME
fi

Answer 2

Я создал обходной путь для этой проблемы, пока AWS не создаст ECS UpdatePolicy и CreationPolicy, которые позволяют использовать сигнализацию ресурсов:

Использовать AWS::CloudFormation::WaitConditionс макросом, который создаст новые ресурсы WaitCondition, когда ожидается обновление службы. Сообщите об условии ожидания с помощью несущественного контейнера, прикрепленного к задаче.

Пример: https://github.com/deuscapturus/cloudformation-macro-WaitConditionUpdate/blob/master/example-ecs-service.yaml

Макрос для приведенного выше примера можно найти здесь: https://github.com/deuscapturus/cloudformation-macro-WaitConditionUpdate

Answer 3

Если ваше WaitCondition находится в оригинальном создании, вам нужно переименовать его (и Handle). Как только условие ожидания было сообщено как выполненное, оно всегда будет выполнено. Если вы переименуете его и сделаете обновление, исходные WaitCondition и Handle будут удалены, а новые созданные будут созданы и проинформированы.

Если вы не хотите изменять свой шаблон, вы можете использовать ресурсы Lamba и Custom для создания уникального условия ожидания с помощью aws cli для каждого обновления.

Answer 4

В настоящее время это невозможно с предоставленными типами CloudFormation. У меня та же проблема, и я мог бы создать собственный ресурс CloudFormation (используя AWS Lambda), чтобы заменить мой AWS::ECS::Service.

Другой альтернативой является использование вложенных стеков для упаковки ресурсов AWS:: ECS:: Service - это не решит проблему, но, по крайней мере, изолирует отдельную службу, а остальная часть стека будет в хорошем состоянии. Мои стеки имеют несколько сервисов, и это помогло бы, но пользовательский ресурс - лучший вариант (я знаю других людей, которые делали то же самое).