У меня есть приложение с балансировкой нагрузки Python Elastic Beanstalk. Вот путь, по которому пользовательский запрос попадает в приложение Elastic Beanstalk:
user -> Elastic Beanstalk ELB -> Elastic Beanstalk mod_wsgi
Эта проблема:
Первые ~ 2-4 запроса от user после eb deploy новой версии приложения будет генерировать 504 ошибки из ELB.
После этих ~ 2-4 запросов, генерирующих 504, все в порядке! 200 вокруг.
Когда происходит ошибка 504, ноль запросов доходит до Elastic Beanstalk mod_wsgi приложение согласно /var/httpd/access_log. Я вижу 200 только после того, как ELB решил снова начать работать.
То, что я пробовал, но не сработало:
Elastic Beanstalk ELB Тайм-аут простоя до 300 секундElastic Beanstalk mod_wsgi Apache KeepAliveTimeout до 300 секунд, как предлагается здесь: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/ts-elb-error-message.htmlМожно сказать: «просто живите с 504-ми!»
Однако настоящая проблема заключается в том, что в моей производственной установке у меня CloudFlare между user и Elastic Beanstalk ELB. CloudFlare настроен на агрессивное кеширование .css и .js файлы, так как я добавляю хеши md5 к URL-адресам статических файлов. Когда запросы этих важных файлов завершаются ошибкой с кодом 504, CloudFlare, похоже, кэширует эти сбои как ошибки 404. Дальнейшие запросы этих файлов 404, нарушая тем самым визуальный стиль сайта при каждом развертывании.
Развертывание приложения Elastic Beanstalk очередной раз с той же версией приложения исправит проблему CloudFlare 404. Это не лучшее решение. Я хочу продолжать использовать CloudFlare, потому что он обеспечивает отличный прозрачный CDN, поэтому избавление от него тоже не является решением.
Трудно поверить, что я один с этой проблемой, но Google, stackoverflow / serverfault и форумы AWS не предоставили никаких решений или даже подобных отчетов о проблемах. Я надеюсь, что мое описание этого поведения зазвонит кому-нибудь здесь. Заранее спасибо.
У меня была точно такая же проблема, которую я действительно считаю ошибкой в программе развертывания Beanstalk.
Я использовал «скользящую» политику развертывания с 2 экземплярами и размером пакета 1, что теоретически должно давать нулевое время простоя. Однако на самом деле во время развертывания все еще есть период около 10-15 секунд, когда ELB отвечает 504.
Взгляните на настройки «Обновление и развертывание» в конфигурации beanstalk. Я обнаружил, что переход на «Прокат с дополнительным пакетом» и использование размера пакета 100% работает хорошо и дает нулевое время простоя во время обновления.
Обновление октябрь 2018 г. - Я не знаю, как долго это работает, но непрерывные обновления Elastic Beanstalk теперь снова работают правильно, без простоев для меня.
Если вы столкнетесь с этим, я обнаружил, что эта проблема также может возникнуть, если вы неправильно настроили конечную точку «проверки работоспособности». EB будет переключать серверы на балансировку нагрузки только после того, как EB будет получать «исправные» ответы от конечной точки проверки работоспособности, которая по умолчанию, я думаю, просто проверяет, что ваш сервер (nginx / apache / other для веб-приложений) реагирует, а не то, что ваш приложение правильно запущено.
В моем случае фактический веб-сервер реагировал до того, как мое приложение Flask было полностью запущено, что привело к ротации серверов до того, как они были готовы. Я добавил в свое приложение Flask конечную точку, которая просто возвращает 200 и фиктивное тело JSON, и указал EB в качестве проверки работоспособности. С тех пор все идет гладко.