LINUX.ORG.RU

Docker и php worker`ы в контексте очередей (rabbitmq)

 , , ,


0

3

Добрый день!

Сразу оговорюсь, речь идет о dev-окружении, до прода еще далеко.

Хочу заюзать очереди. PHP 7.2 крутится на apache на чистом образе из Ubuntu 18.04 LTS. Управляю через docker-compose. Встал вопрос, а как запускать слушателя очереди (или демона-обработчика очереди), ведь один процесс - один контейнер и все такое ... ?

Ну как всегда есть вариант с Supervisor. Вариант знаком мне по предыдущим образам, там в основе как раз был image, который держал apache бэкграундным процессом с помощью Supervisor.

Дело вроде бы нехитрое и даже воркеров можно сколько угодно наплодить в одном контейнере, пока они всю память не выжрут, но что-то меня держит за душу. Ну и я всегда изучаю новое с прицелом «а как потом все таки в проде это будет работать».

Есть идея сделать каждый воркер отдельным контейнером, но возможно, будет геморрой, когда нужно будет убить воркер. Я про команду php artisan queue:restart. Она мягко убивает воркеров, чтобы не потерять задачи и высвобождает ресурсы. Как я понимаю, процедура эта потребуется часто, т.к. будут они со временем повисать и терять коннект к БД, в которую они должны писать инфу о проваленных задачах. Еще из минусов, вероятно, при большом количестве воркеров сильно вырастет docker-compose.yml, что не сильно приятно и удобно, хотя и не супер критично.

Кто подскажет, как такие вещи делают? Инфы мало нашел по теме, увы.

P.S. я мог быть неточен в терминологии или даже по-крупному что-то напутать, заранее прошу прощения, я только начинаю работать с очередями. К примеру, worker, в моем понимании - тот процесс, который выполнит задачу, но как он связан со слушателем очереди (или демоном-обработчиком очереди), я не очень представляю. Вроде бы как раз этот слушатель сам умеет управлять воркерами. Если считает, что тот умер, создаст нового (и тут не совсем понятно, как отработает supervisor). В общем поправьте, кто в теме.

P.S. уже напутал: тот процесс, который запускается с помощью php artisan queue:work - и есть «воркер», он же демон, при запуске с опцией --daemon. И именно его будет реанимировать supervisor. Неплохой перевод доки laravel по самим очередям https://laravel.ru/docs/v5/queues



Последнее исправление: root93 (всего исправлений: 10)
Ответ на: комментарий от gadzira

С rabbit`ом порядок, крутится в отдельном контейнере.

Я не знаю, как присобачить обработчик очереди. Основная дилемма - в отдельных контейнерах или все в том же, где apapche+php.

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

root93
() автор топика
Ответ на: комментарий от root93

Когда ты говоришь «слушатель», ты имеешь ввиду consumer'а? и кто такой «обработчик» тогда?

gadzira
()

Каждому воркеру по контейнеру.

stave ★★★★★
()
Ответ на: комментарий от root93

Основная дилемма - в отдельных контейнерах или все в том же, где apapche+php

В отдельных конечно. В идеале они должны динамически запускаться/останавливаться в количестве зависимом от текущей нагрузки. Т.е. нужно накинуть сверху swarm/kubernetes чтобы автоматом масштабировать количество инстансов.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Да, воркер в терминологии php = обработчик очередей в терминологии laravel = consumer в терминологии кролика.

stave, no-such-file, спасибо за ответы! Я так и думал, что скорее всего отдельные. Просто пугал тот факт что все эти контейнеры-воркеры будут подключать volume с кодом одновременно и что каждый будет к базе отдельный коннект создавать. Наверно глупые страхи. Volumes по идее работают стабильно при подключении к нескольким контейнерам, а демоны к базе не так-то часто и будут ломиться, только в случае проваленных тасков.

root93
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.