Мои задачи djcelery выполняются локально, но не удаленно?

Question

У меня есть автоматические задачи, работающие локально, но не переориентированные в моем приложении django. Я смотрел учебник, и парень сказал, чтобы остановить моего работника. но прежде чем я сделал это, я положил свое приложение в режим обслуживания, это не сработало. Затем я побежал

heroku ps:restart 

, которая не работала, то я побежал

heroku ps:stop worker 

который outputed

Warning: The dynos in your dyno formation will be automatically restarted. 

тогда я побежал

heroku ps:scale worker=1 

и до сих пор ничего. Я напоминаю тем, кто читает это, что он работает на местном уровне. Что мне не хватает?

мой PROCFILE

web: gunicorn gettingstarted.wsgi --log-file - 
worker: celery worker -A blog -l info. 

При исследовании я вижу упоминания о добавлении бить в PROCFILE. 2 фактически упоминается, но это не обсуждалось в учебнике, которое я смотрел. Единственный раз, когда упоминалось сельдерей биений, когда я добавил это в файле settings.py

CELERYBEAT_SCHEDULER = 'djcelery.schedulers.DatabaseScheduler' 

и только в случае, если это имеет значение, я использую djcelery графический интерфейс для установки периодических задач, не настраивая sceduler в настройках .py, как я вижу в большинстве примеров.

Если я запускаю задачу на своем экране и называю ее, она работает. Но он не будет работать, если я установить его с помощью djcelery

Answer 1

Я прочитал документацию и понял, что я должен был добавить к моему рабочему PROCFILE

-B 

так теперь выглядит следующим образом

celery -A proj worker -B -l info 

после Я сделал изменения, я сделал это

heroku ps:scale worker=0 

затем

git add . 
git commit -am 'added -B' 
git push heroku master 

я

heroku ps:scale worker=1 

то, чтобы я мог видеть на выходе из Heroku

heroku logs -t -p worker 

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

Answer 2

Как вы прочитали в документах, использование опции -B не рекомендуется для использования в производственных целях, d лучше запустить celery-beat как другой процесс.

Так что лучше практика, чтобы запустить его на сервере, как:

celery beat -A messaging_router --loglevel=INFO 

И если вы используете supervisor сохранить ваши процессы, запущенные, вы бы добавить что-то вроде следующего в файл конфигурации.

[program:api_beat] 
command=/path/to/v_envs/v_env/bin/celery -A project beat --loglevel=info 
autostart=true 
autorestart=true 
user=your_user (echo $USER) 
directory=/path/to/project/root 
stdout_logfile=/var/log/supervisor/beat.log 
stderr_logfile=/var/log/supervisor/beat.log 
redirect_stderr=true 
environment=EVN_VAR1="whatever", 

Причина этого заключается в том, как документы говорят

Вы также можете начать вставлять бит внутри работника, позволяя работник -B варианта, это удобно, если вы никогда не будете работать более одного сотрудника но он не используется обычно и по этой причине не рекомендуется для использования в производстве:

Рассмотрите, что у вас более 1 работника, в техническом обслуживании, вам всегда нужно быть разными, из которых один из работников сельдерея, с пробегом -B, и это определенно может быть бременем.