Spring-cloud-netflix нулевое время простоя развертывания в AWS ECS - PullRequest
Новая
       22

Spring-cloud-netflix нулевое время простоя развертывания в AWS ECS

0 голосов
/ 26 августа 2018

Мы работаем с микросервисами Spring-Cloud, используя eureka в AWS ECS.Мы также проводим непрерывное развертывание, и мы столкнулись с проблемой, когда развертывание производственных развертываний приводит к короткому периоду недоступности службы.Я сосредотачиваюсь здесь на клиентах @LoadBalanced RestTemplate, использующих ленту.Я думаю, что я получил адекватную повторную работу в своей локальной среде тестирования, но меня беспокоит время задержки регистрации eureka нового экземпляра службы и то, как работают развертывания ECS.

Когда мы объединяем новый коммит с мастером, если сборка проходит (компилируется и проходит тестирование), наш конвейер jenkins создает и передает новый образ докера в ECR, затем создает новую редакцию определения задачи ECS, указывающую на обновленный образ докера, и обновляет службу ECS.Например, у нас есть определение службы ECS с желаемым числом задач, установленным на 2, минимальным доступным процентом, установленным на 100%, и максимальным доступным процентом, установленным на 200%.Планировщик службы ECS запускает 2 новых контейнера докеров, используя новый образ, оставляя существующий 2 контейнера докеров работающим на старом образе.Мы используем проверки работоспособности контейнеров, которые проходят, когда конечная точка работоспособности привода возвращает 200, и как только это происходит, планировщик службы ECS останавливает 2 старых контейнера, работающих на старом образе докера.

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

Я попросил службу поддержки AWS о том, какотложить завершение задачи ECS во время развертывания.Когда службы ECS связаны с целевой группой ALB, существует параметр задержки отмены регистрации, который соблюдает ECS, но такой возможности не существует, если балансировщик нагрузки не задействован.Ответ AWS состоял в том, чтобы запустить java-приложение с помощью bash-скрипта точки входа, например: 

#!/bin/bash

cleanup() {
    date
    echo "Received SIGINT, sleeping for 45 seconds"
    sleep 45
    date
    echo "Killing child process"
    kill -- -$$
}

trap 'cleanup' SIGTERM

"${@}" &

wait $!

Когда ECS завершает работу старых экземпляров, он отправляет SIGTERM в контейнер Docker, этот скрипт перехватывает его, спит в течение 45 секунд., затем продолжается с выключением.Мне также придется изменить параметр конфигурации ecs в / etc / ecs, который управляет льготным периодом до того, как ECS отправит SIGKILL после SIGTERM, который по умолчанию равен 30 секундам, что не достаточно долго.

Эточувствует себя грязным для меня.Я не уверен, что сценарий не вызовет какую-то другую непредвиденную проблему;он передает все сигналы соответственно?Это похоже на нежелательное осложнение.

Я что-то упустил?Может ли кто-нибудь заметить что-то не так с предлагаемым сценарием точки входа поддержки AWS?Есть ли лучший способ справиться с этим и достичь желаемого результата, а именно: нулевое время простоя при развертывании служб, зарегистрированных в eureka в ECS?

...