Когда эластичный балансировщик нагрузки (ELB) связан с группой с автоматическим масштабированием, можно указать период отсрочки, в течение которого новые экземпляры EC2 не будут завершены, даже если они помечены ELB как неисправные. Можно ли указать аналогичный период отсрочки, в течение которого новые задачи ECS не будут уничтожаться и перезапускаться связанной с ними службой ECS, даже если экземпляр ECS, на котором выполняется задача, был помечен ELB как неработоспособный?
Обновить:
В нашем текущем варианте использования контейнер докеров, запускаемый как задача ECS, содержит экземпляр JBoss, который загружает несколько кешей при запуске. Загрузка этих кешей может занять несколько минут. Однако служба ECS регистрирует экземпляр контейнера в ELB, как только контейнер запускается. Это означает, что трафик может быть направлен в новый контейнер до того, как он будет готов его принять. Мы могли бы увеличить интервал проверки работоспособности и «пороговые значения работоспособности / неработоспособности» на ELB, чтобы предотвратить маршрутизацию трафика от ELB к экземпляру и перезапуск службы ECS контейнера до тех пор, пока кеши не будут загружены. Однако увеличение интервала проверки работоспособности и пороговых значений нежелательно, потому что, если экземпляр помечен как неисправный после загрузки кешей, служба ECS должна перезапустить контейнер как можно скорее (что требует более короткого интервала проверки работоспособности и меньших пороговых значений. ).
Таким образом, возможно ли применить льготный период, в течение которого трафик не будет перенаправляться на новый контейнер с помощью ELB, а служба ECS не будет перезапускать контейнер (даже если он не пройдет проверку работоспособности)? Или, если это не удается, есть ли какие-либо предложения относительно решения для нашего варианта использования?
После обсуждения со службой поддержки выяснилось, что 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) и марафон (https://mesosphere.github.io/marathon/docs/health-checks.html) уже поддерживают эту опцию для проверки работоспособности, если кто-то, читающий ее, не будет использовать управляемую службу.