Comments 16
А вот в среде AWS EB, мы уже не сможем устанавливать свои cron файлы или работать с очередью напрямую:
Поясните человеку, который поверхностно знаком с AWS EB и Laravel, а что все-таки мешает установить свой cron-файл в среде AWS EB? Ведь насколько я понимаю, в AWS EB с помощью файлов конфигурации (.ebextensions/something.config) вы можете выполнять любые команды внутри инстанса EC2, которые будут выполняться при развертке, в том числе добавить задачу в cron, нет?
Добавить задачу в cron можно, но в этом случае эта задача добавится в cron на всех EC2 инстансах. Соответственно, задача запустится в означенное время на всех инстансах, что обычно нежелательно.
Да, mitja ответил за меня :) Такой способ не рекомендуется в документации AWS. Проблемы тоже никак обрабатываться не будут.
UFO just landed and posted this here
А Вы обратите внимание на постскриптум в Вашей же ссылке:
Update: There is an issue with this solution when Elastic Beanstalk scales up your instances. For example, lets say you have one instance with the cron job running. You get an increase in traffic so Elastic Beanstalk scales you up to two instances. The leader_only will ensure you only have one cron job running between the two instances. Your traffic decreases and Elastic Beanstalk scales you down to one instance. But instead of terminating the second instance, Elastic Beanstalk terminates the first instance that was the leader. You now don't have any cron jobs running since they were only running on the first instance that was terminated. See the comments below.)
Если этого недостаточно, напомню еще про несимметричную нагрузку в таком сценарии – один instance будет всегда иметь больше нагрузки, чем другие. Кроме того, неработающий скрипт, я предполагаю, не будет показан в health-статусе приложения, а вот если перестанет работать веб-хук, то будет HTTP ошибка и разработчик заметит это по статусу.
Update: There is an issue with this solution when Elastic Beanstalk scales up your instances. For example, lets say you have one instance with the cron job running. You get an increase in traffic so Elastic Beanstalk scales you up to two instances. The leader_only will ensure you only have one cron job running between the two instances. Your traffic decreases and Elastic Beanstalk scales you down to one instance. But instead of terminating the second instance, Elastic Beanstalk terminates the first instance that was the leader. You now don't have any cron jobs running since they were only running on the first instance that was terminated. See the comments below.)
Если этого недостаточно, напомню еще про несимметричную нагрузку в таком сценарии – один instance будет всегда иметь больше нагрузки, чем другие. Кроме того, неработающий скрипт, я предполагаю, не будет показан в health-статусе приложения, а вот если перестанет работать веб-хук, то будет HTTP ошибка и разработчик заметит это по статусу.
Мы хотим, чтобы происходило тоже самое, что происходит при запуска в консоли php artisan schedule:run, но из web-запроса (web-хука).
Если время обработки одного элемента очереди — несколько минут, как поведет себя такая реализация?
Эээ. Ну вообще-то, судя по документации, Laravel вполне дружит с целой кучей всяких разных видов систем обработки очередей, в том числе и Amazon SQS тоже. И по-нормальному, у Laravel есть свой демон, который запускается и эти очереди обрабатывает.
В общем, что-то я не понял тему статьи.
Laravel нормально дружит если Вы его запустите, скажем, в EC2. Проблемы начинаются, когда среда приложения – Elastic Beanstalk. В таком случае, Laravel вообще никак не готов, и уже много месяцев на Laracasts пользователи ищут решение :)
В Elastic Beanstalk нельзя (точнее, от Вас этого не ожидается) запускать дополнительные демоны.
В Elastic Beanstalk нельзя (точнее, от Вас этого не ожидается) запускать дополнительные демоны.
В стандартном процессе, Laravel вставляет задачи в очередь, а другая копия этого же приложения опрашивает очередь периодически, надеясь получить задачу. Запланированные задачи обрабатываются внутренним планировщиком Laravel, который в свою очередь запускается каждую минуту через стандартный UNIX cron tab.Под «стандартным процессом» вы подразумеваете, что слушатель очередей работает именно так везде, кроме ЕВ? Если да, то это вы что-то себе костыльное придумали, так слушателя на шареде запускать можно, когда ни ssh нету, ни супервизора не настроить, ни процесс отдельный запустить.
Очереди в Laravel работают без cron'а, там бесконечный цикл который опрашивается BD, Redis, Beanstalkd, Amazon SQS или IronMQ на наличие задач. А вот schedule как раз служит для управление крон задачами из приложения, без необходимости лазить в crontab на сервере.
Вы тут спутали 2 понятия, и запутали себя и читателей.
Вы тут спутали 2 понятия, и запутали себя и читателей.
Нет, ничего не перепутал :) Просто эти две функции, как правило, вынесены на worker instances. Поэтому я показал как обе функции развернуть в Elastic Beanstalk.
php artisan queue:listen действительно запускает бесконечный цикл, но как Вы запустите его из worker, без доступа к консоли, supervisor или cron tab?
AWS не хочет, чтобы разработчики на worker работали «напрямую» с очередями.
php artisan queue:listen действительно запускает бесконечный цикл, но как Вы запустите его из worker, без доступа к консоли, supervisor или cron tab?
AWS не хочет, чтобы разработчики на worker работали «напрямую» с очередями.
UFO just landed and posted this here
Все равно будет один минус упомянутый выше – команда будет работать на всех instances.
Еще, совсем забыл упомянуть в статье, я использую Docker-вариант Elastic Beanstalk, потому что 1) у Amazon до сих пор нет PHP 7 2) Docker – это удобно.
И тут, насколько я понимаю, .ebextensions сразу отпадает – это команды, которые будут в host OS запускаться, а не в контейнере. Можно, конечно, в Dockerfile установить supervisor, но будет проблема из первого предложения :)
При работе с планировщиком через очереди, как предложено в статье, неудачные задачи будут корректно в Dead Messages очередь перемещены, и не важно сколько в EB инстансов, 1 или 500, каждая задача будет выполнена один раз.
Еще, совсем забыл упомянуть в статье, я использую Docker-вариант Elastic Beanstalk, потому что 1) у Amazon до сих пор нет PHP 7 2) Docker – это удобно.
И тут, насколько я понимаю, .ebextensions сразу отпадает – это команды, которые будут в host OS запускаться, а не в контейнере. Можно, конечно, в Dockerfile установить supervisor, но будет проблема из первого предложения :)
При работе с планировщиком через очереди, как предложено в статье, неудачные задачи будут корректно в Dead Messages очередь перемещены, и не важно сколько в EB инстансов, 1 или 500, каждая задача будет выполнена один раз.
Sign up to leave a comment.
Запускаем очереди и планировщик Laravel в среде Elastic Beanstalk