Запуск порта 80 колбы на работнике из эластичного бобового стебля - PullRequest
0 голосов
/ 11 сентября 2018

Учитывая поле AWS Elastic-Beanstalk Worker, возможно ли использовать Flask / port: 80 для обслуживания сообщений, поступающих из связанной очереди SQS?

Я видел противоречивую информацию о том, что происходит внутри ELB-работника. Страница ELB Worker Environment гласит:

Elastic Beanstalk упрощает этот процесс, управляя очередью Amazon SQS и запуская процесс демона в каждом экземпляре, который читает для вас эту очередь. Когда демон извлекает элемент из очереди, он локально отправляет запрос HTTP POST на http://localhost/ на порт 80 с содержимым сообщения очереди в теле. Все, что нужно вашему приложению - это выполнить долгосрочную задачу в ответ на POST.

Этот вопрос SO Отличия веб-сервера от Worker говорит:

Самым важным отличием на мой взгляд является то, что экземпляры рабочего уровня не запускают процессы веб-сервера (apache, nginx и т. Д.).

Исходя из этого, я ожидал, что смогу просто запустить Flask-сервер на порту 80, и он будет обрабатывать сообщения SQS. Тем не менее, сообщение кажется неправильным. Даже на ящиках ELB-работника работает Apache, очевидно, для проверки работоспособности (когда я его остановил, мой сервер покраснел). И конечно он использует порт 80 ...

У меня уже есть Flask / Gunicorn на сервере EC2, который я пытался переместить на ELB, и я хотел бы продолжать использовать это - возможно ли это? (Примечание: демон очереди отправляет только сообщения на порт 80, которые нельзя изменить ...)

Документы не ясны, но, похоже, они ожидают, что вы измените Apache на Proxy, чтобы использовать Flask, возможно? Я надеюсь, что это не единственный способ.

Или, каков "правильный" способ настройки ELB-работника для обработки сообщений SQS? Как вы должны «выполнить долгосрочное задание»?

Примечание : теперь, когда я больше использовал ELB и достаточно хорошо его понимаю, позвольте мне пояснить, что это не сценарий использования, разработанный Amazon ELB-работники для, и у него есть некоторые глюки (которые будут отмечены). Стандартный вариант использования, по сути, заключается в том, что вы создаете простое приложение Flask и подключаете его к серверу ELB-EC2, который настроен для упрощения запуска этого приложения Flask.

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

1 Ответ

0 голосов
/ 18 октября 2018

Рабочий ELB подключен к очереди SQS демоном, который прослушивает эту очередь и (внутренне) отправляет любые сообщения на http://localhost:80. Apache прослушивает порт 80. Это необходимо для проверки работоспособности., которые выполняет менеджер ELB (или что-то в экосистеме).Apache передает запросы проверки работоспособности, используя mod_wsgi, в загруженное приложение Flask, которое находится по адресу:

/opt/python/current/app/application.py

Я подозреваю, что было бы возможно, но трудно удалить Apache и обработать работоспособность.проверяет другой способ (колбу), освобождая порт 80. Но этого достаточно, и я решил, что оно того не стоит.

Итак, решение, которое я нашел, состоит в том, чтобы изменить порт локального демона.отправлять сообщения - перенастроив его через конфигурационный файл YAML, он отправит сообщение на порт 5001, где работало мое приложение Flask.Это означает, что Apache может продолжать обрабатывать проверки работоспособности на порту 80, а Flask может обрабатывать сообщения SQS от демона.

Вы настраиваете демона и останавливаете / запускаете его (как root):

/etc/aws-sqsd.d/default.yaml
/opt/elasticbeanstalk/addons/sqsd/hooks/stop-sqsd.sh
/opt/elasticbeanstalk/addons/sqsd/hooks/start-sqsd.sh
/opt/elasticbeanstalk/addons/sqsd/hooks/restart-sqsd.sh

Фактический демон:

/opt/elasticbeanstalk/lib/ruby/bin/aws-sqsd
/opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.2.0/gems/aws-sqsd-2.3/bin/aws-sqsd

Глюки: Если вы когда-либо используете графический интерфейс ELB для настройки параметров демона, он перезапишет файл конфигурации, и вам придется заново редактироватьПорт (и перезапустите демон).

Примечание. Весь HTTP-трафик является внутренним, либо для экосистемы ELB, либо для рабочего - поэтому можно закрыть все внешние порты (Iоставьте 22 открытым), например, порт 80. В противном случае ваш рабочий имеет Apache, отвечающий на сообщения http://:80, что означает, что он открыт для всего мира.Я предполагаю, что сервер настроен довольно надежно, но порт 80 вообще не нужно открывать для проверки работоспособности или чего-либо еще.

...