Льготный период? - Устройства балансировки контейнеров AWS EC2 и балансировочные балансировочные нагрузки

Question

Когда эластичная балансировка нагрузки (ELB) связана с группой автоматического масштабирования, можно указать льготный период, в течение которого новые экземпляры EC2 не будут прекращены, даже если они отмечены как нездоровый ELB. Можно ли указать аналогичный льготный период, в течение которого новые задачи ECS не будут убиты и перезапущены их ассоциированной службой ECS, даже если экземпляр ECS, на котором выполняется задача, был отмечен нездоровым ELB?

Update:

В нашем случае использования, контейнер докер быть запущен в качестве задачи ECS содержит экземпляр JBoss, который загружает несколько кэшей при запуске. Эти кеши могут занять несколько минут. Тем не менее, служба ECS регистрирует экземпляр контейнера с помощью ELB, как только контейнер запускается. Это означает, что трафик может быть перенаправлен в новый контейнер, прежде чем он будет готов принять его. Мы могли бы увеличить интервал проверки работоспособности и «здоровые/нездоровые пороги» на ELB, чтобы ELB не тратил трафик на экземпляр и службу ECS от перезапуска контейнера до загрузки кешей. Однако увеличение интервала проверки работоспособности и пороговых значений нежелательно, поскольку если экземпляр отмечен как нездоровый после загрузки кэшей, служба ECS должна как можно скорее перезапустить контейнер (что требует более короткого интервала проверки работоспособности и меньших пороговых значений).

Таким образом, можно применить льготный период, в течение которого трафик не будет перенаправлен в новый контейнер с помощью ELB, и служба ECS не перезапустит контейнер (даже если он не прошел проверку работоспособности)? Или, если это не так, есть ли какие-либо предложения относительно решения для нашего случая использования?

Answer 1

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

Существует обходное решение, которое решает одну из проблем, с которыми мы сталкиваемся. Этот способ заключается в создании отдельного, необходимого, контейнера проверки работоспособности и той же задачи ECS, что и фактический контейнер приложения. Цель контейнера для проверки работоспособности - контролировать контейнер приложения, чтобы определить, когда приложение было полностью запущено. Если он обнаруживает, что приложение не удалось запустить, оно завершается, заставляя службу ECS выполнять цикл задачи. Затем ELB сконфигурирован для выполнения своих проверок работоспособности с контейнером проверки работоспособности, который всегда будет сообщать, что он подключен через соответствующий порт. Это обходное решение не позволит службе ECS циклически запускать задачу ECS из-за неудачных проверок работоспособности.

Однако ELB начнет маршрутизацию трафика в контейнер приложения немедленно. Он сделает это, даже если контейнер приложения еще не готов к приему трафика (например, поскольку он все еще ожидает загрузки кеша). В настоящее время нет возможности отложить ELB от отправки трафика в контейнер приложения, так как служба ECS не поддерживает период льгот. Нам удалось решить эту проблему, отправив сообщения в наши контейнеры приложений через SQS и только вытащив их из очереди, когда их кеши полностью загружены. Тем не менее, у нас есть будущие варианты использования (например, обслуживание веб-запросов), где это невозможно. С этой целью я намерен поднять запрос функции на льготный период.

Как и в случае с Kubernetes (http://kubernetes.io/v1.0/docs/user-guide/walkthrough/k8s201.html#application-health-checking) и Marathon (https://mesosphere.github.io/marathon/docs/health-checks.html), этот вариант поддержки для проверки работоспособности уже поддерживается, если кто-то читает это, счастлив не использовать управляемую услугу.

Answer 2

Использование окр вар ECS_CONTAINER_STOP_TIMEOUT

См https://github.com/aws/amazon-ecs-agent/issues/126