Я тестировал текущие обновления ECS в режиме DAEMON и не могу избежать случайных ответов "502 Bad Gateway". Вот что я сделал, чтобы проверить это, что, похоже, указывает на ошибку в процессе стратегии слива.
Для начала я написал минимальную программу hello-world в Котлине / Джерси, которая отвечает на curl GET ( source ). Я бью конечную точку в цикле каждые ~ 300 мс:
while [ 1 ]; do curl -s http://...us-east-2.elb.amazonaws.com/helloWorld | ts '[%Y-%m-%d %H:%M:%S]'; echo ""; sleep 0.3; done
Затем я помещаю новое изображение контейнера (используя тот же тег), которое дает немного другой ответ (110 против 1010), чтобы я мог наблюдать за процессом развертывания. Наконец я принудительно обновляю сервис с помощью:
aws ecs update-service --service service-helloworld-jersey --cluster cluster-helloworld-jersey --force-new-deployment
У меня есть две задачи в моей службе и 50% в Минимальный процент работоспособности . Цикл Bash производит следующий вывод во время непрерывных обновлений - в какой-то момент есть два выхода, один с «110» (старый код), а другой с «1010» (новый код), это после того, как один из контейнеров имеет был обновлен, а другой по-прежнему не имеет:
Если вы коррелируете события на консоли Bash с событиями на консоли AWS (оба синхронизируются по NTP), вы можете увидеть, что около 9:04:39 мы все еще используем старый код / контейнер, несмотря на «истощающее» событие, предположительно происходящее с 9:04:28, которое я выделил красным ниже. В 9:04:39 задача, наконец, остановлена, что соответствует ответу "502 Bad Gateway" в цикле.
Мой вывод заключается в том, что ELB неправильно истощает последнюю цель, что приводит к ошибке, которую мы видим.
Если у кого-то есть мысли, как диагностировать это дальше или настроить по-другому, пожалуйста, дайте мне знать.
Мне удалось избежать прерывания обслуживания, увеличив задержку отмены регистрации ELB с 10 до 30 секунд.
