Помечает ли команда ECS update-service состояние экземпляра контейнера для опустошения при использовании с параметром --force-new-deploy? - PullRequest
0 голосов
/ 24 апреля 2020

Команда:

aws ecs update-service --service my-http-service --task-definition amazon-ecs-sample --force-new-deployment

Согласно AWS документам: вы можете использовать эту опцию (--force-new-deploy) для запуска нового развертывания без изменений определения сервиса. Например, вы можете обновить задачи службы, чтобы использовать более новое Docker изображение с той же комбинацией изображения / тега (my_image: latest) или перенести задачи Fargate на более новую версию платформы.

Мой вопрос, если Я использую «--force-new-deploy» (как я буду использовать существующий тег или определение), будет ли подчеркивающее значение «Экземпляр ECS» автоматически установлено в состояние DRAINING, чтобы любая новая задача (если таковая имеется) не запускалась в СУЩЕСТВУЮЩИЙ экземпляр ecs, который предположительно будет go удален во время стратегии развертывания с непрерывным обновлением (или контроллера развертывания)?

Другими словами, будет ли шанс:

  1. Для новой задачи, которая будет создана на существующем / старом экземпляре контейнера, которая должна быть удалена на go во время обновления обновления.

  2. Кроме того, что произойдет с текущей задачей который работает на этом существующем / старом экземпляре контейнера, который, как предполагается, должен go отойти во время обновления обновления.

Ref: https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html

1 Ответ

1 голос
/ 24 апреля 2020

Обратите внимание, что с этой командой update-service экземпляр контейнера никуда не денется. Эта команда создаст только новое развертывание в службе ECS, и когда новые задачи станут работоспособными, удалите старые задачи.

Редактировать 1:

Как насчет запроса которые были обработаны старой задачей?

Я предполагаю, что задачи лежат в основе Application Load Balancer. В этом случае старые задачи будут отменены из ALB.

Примечание. В следующем обсуждении целью является задача ECS.

Чтобы дать вам краткое описание о том, как задержка отмены регистрации работает с ECS, ниже приведен последовательный порядок остановки задачи, связанной с ALB. Это может быть связано с масштабом события, развертыванием определения новой задачи, уменьшением количества задач, принудительным развертыванием и т. Д. c.

  1. ECS отправляет вызов DeregisterTargets и цели меняют статус на «слив». Новые соединения не будут обслуживаться этим целям.

  2. Если время задержки отмены регистрации истекло и все еще есть запросы в полете, ALB прекратит их, и клиенты получат ответы 5XX, полученные из ALB.

  3. Цели отменены из целевой группы.

  4. ECS отправит стоп-вызов задачам и агенту ECS будет корректно останавливать контейнеры (SIGTERM).

  5. Если контейнеры не останавливаются в течение времени ожидания остановки (ECS_CONTAINER_STOP_TIMEOUT по умолчанию 30 с), они принудительно останавливаются (SIGKILL).

Согласно документации ELB [1], если у цели отмены регистрации нет запросов в полете и нет активных соединений, Elasti c Балансировка нагрузки немедленно завершает процесс отмены регистрации, не ожидая задержки отмены регистрации для Elapse. Однако даже если отмена регистрации цели завершена, состояние цели будет отображаться как удаление, и вы можете видеть, что зарегистрированная цель старой задачи все еще присутствует в консоли TargetGroup со статусом удаления, пока не истечет задержка отмены регистрации.

Целью ECS является остановка Задачи после завершения процесса Слива, как упомянуто в документе ECS [2], и, следовательно, Служба ECS ожидает, пока TargetGroup завершит процесс Слива, прежде чем выполнить вызов остановки.

Ссылка:

[1] Целевые группы для вашего приложения Балансировщики нагрузки - Задержка отмены регистрации - https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-задержка

[2] Обновление Сервис - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html

...