Django-Настроить Запланированную Работу?
Я работал над веб-приложением с помощью Django, и мне интересно, есть ли способ запланировать работу для периодического запуска.
в основном я просто хочу запустить базу данных и сделать некоторые вычисления/обновления на автоматической, регулярной основе, но я не могу найти никакой документации по этому вопросу.
кто-нибудь знает как это настроить?
чтобы уточнить: я знаю, что могу настроить cron
работа для этого, но мне любопытно, есть ли какая-то функция в Django, который предоставляет эту функциональность. Я хотел бы, чтобы люди могли развернуть это приложение сами, не делая много конфигурации (предпочтительно ноль).
Я рассмотрел возможность запуска этих действий "задним числом", просто проверив, должно ли было выполняться задание с момента последней отправки запроса на сайт, но я надеюсь на что-то более чистое.
21 ответов
одно из решений, которое я использовал, - это сделать следующее:
1) Создать управление командой, например,
python manage.py my_cool_command
2) Использовать cron
(в Linux) или at
(в Windows) для запуска моей команды в нужное время.
Это простое решение, которое не требует установки тяжелого стека AMQP. Однако есть хорошие преимущества в использовании чего-то вроде сельдерея, упомянутого в других ответах. В частности, с сельдереем приятно не необходимо распространить логику приложения в файлы crontab. Однако решение cron работает довольно хорошо для приложений малого и среднего размера и где вам не нужно много внешних зависимостей.
EDIT:
в более поздней версии windows at
команда устарела для Windows 8, Server 2012 и выше. Вы можете использовать schtasks.exe
для такого же использования.
сельдерей - распределенная очередь задач, построенная на AMQP (RabbitMQ). Он также осуществляет периодические задачи в хрон-как мода (см. периодические задачи). В зависимости от вашего приложения, это может быть стоит взглянуть.
сельдерей довольно легко настроить с помощью django (docs), а периодические задачи фактически пропускают пропущенные задачи в случае простоя. Сельдерей также имеет встроенные механизмы повтора, в случае неудачи задачи.
мы с открытым исходным кодом, что я думаю, является структурированным приложением. это решение Брайана выше тоже намекает. Хотел бы любой / все отзывы!
https://github.com/tivix/django-cron
он поставляется с одной командой управления:
./manage.py runcrons
это делает работу. Каждый cron моделируется как класс (так что все его OO), и каждый cron работает на разной частоте, и мы удостоверяемся, что тот же тип cron не работает параллельно (в случае, если сами кроны занимают больше времени бежать, чем их частота!)
спасибо!
интересное новое подключаемое приложение Django:Джанго-хронограф
вам нужно добавить только одну запись cron, которая действует как таймер, и у вас есть очень хороший интерфейс администратора Django в скрипты для запуска.
посмотрите на Cron бедного человека Django, который является приложением Django, которое использует спам-ботов, поисковых роботов индексирования и так, чтобы запускать запланированные задачи примерно через регулярные промежутки времени
RabbitMQ и сельдерей имеют больше функций и возможностей обработки задач, чем Cron. Если сбой задачи не является проблемой, и вы думаете, что будете обрабатывать сломанные задачи в следующем вызове, то Cron достаточно.
сельдерей & AMQP позволит вам справиться с сломанной задачей, и она будет снова выполнена другим работником (работники сельдерея слушают следующую задачу для работы), пока задача max_retries
атрибут достигнут. Вы даже можете вызывать задачи при сбое, например сбой или отправка электронной почты администратору после max_retries
была достигнута.
и вы можете распространять серверы сельдерея и AMQP, когда вам нужно масштабировать приложение.
Я лично использую cron, но Планирование Заданий разделы django-расширения выглядит интересно.
поместите следующее в верхней части cron.py файл:
#!/usr/bin/python
import os, sys
sys.path.append('/path/to/') # the parent directory of the project
sys.path.append('/path/to/project') # these lines only needed if not on path
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproj.settings'
# imports and code below
Я просто подумал об этом довольно простом решении:
- определите функцию представления do_work (req, param) как и в любом другом представлении, с сопоставлением URL, верните HttpResponse и так далее.
- настройте задание cron с вашими настройками времени (или с помощью AT или запланированных задач в Windows), которое работает curl http://localhost/your/mapped/url?Параметр=Значение.
вы можете добавить параметры, но просто добавление параметров в URL.
скажите мне, что вы думаете.
[обновление] теперь я использую команду runjob из django-расширения вместо curl.
мой cron выглядит примерно так:
@hourly python /path/to/project/manage.py runjobs hourly
... и так далее для ежедневного, ежемесячного, etc. Вы также можете настроить его для выполнения определенной работы.
Я нахожу его более управляемым и чище. Не требует сопоставления URL-адреса с представлением. Просто определите свой класс работы и кронтаб и ты готов.
хотя и не является частью Django,расход является более поздним проектом (по состоянию на 2016 год), который полезен для управления задачами.
Airflow-это система автоматизации рабочего процесса и планирования, которая может использоваться для создания и управления конвейерами данных. Веб-интерфейс предоставляет разработчику ряд опций для управления и просмотра этих конвейеров.
воздушный поток написан на Python и построен с использованием колбы.
воздушный поток был создан Maxime Beauchemin в Airbnb и с открытым исходным кодом весной 2015 года. Он присоединился к инкубационной программе Apache Software Foundation зимой 2016 года. Вот это страница проекта Git и дополнение справочная информация.
некоторое время назад у меня было точно такое же требование, и в итоге я решил его с помощью APScheduler (Руководство Пользователя)
это делает планирование заданий супер простым и сохраняет его независимым от выполнения некоторого кода на основе запросов. Ниже приведен простой пример, который я использовал в своем коде.
from apscheduler.schedulers.background import BackgroundScheduler
scheduler = BackgroundScheduler()
job = None
def tick():
print('One tick!')\
def start_job():
global job
job = scheduler.add_job(tick, 'interval', seconds=3600)
try:
scheduler.start()
except:
pass
надеюсь, это кому-то поможет!
после части кода я могу написать что-нибудь вроде моего views.py :)
#######################################
import os,sys
sys.path.append('/home/administrator/development/store')
os.environ['DJANGO_SETTINGS_MODULE']='store.settings'
from django.core.management impor setup_environ
from store import settings
setup_environ(settings)
#######################################
от http://www.cotellese.net/2007/09/27/running-external-scripts-against-django-models/
У меня было что-то похожее с вашей проблемой сегодня.
Я не хотел, чтобы он обрабатывался сервером trhough cron (и большинство либов были просто помощниками cron в конце).
поэтому я создал модуль планирования и прикрепил его к init .
Это не лучший подход, но он помогает мне иметь весь код в одном месте и с его выполнением, связанным с основным приложением.
Да, метод выше настолько велик. И я попробовал некоторые из них. Наконец, я нашел такой метод:--2-->
from threading import Timer
def sync():
do something...
sync_timer = Timer(self.interval, sync, ())
sync_timer.start()
как рекурсивные.
Ок, я надеюсь, что этот метод может удовлетворить ваши требования. :)
Я использую сельдерей для создания периодических задач. Сначала нужно установить его следующим образом:
pip install django-celery
не забудьте зарегистрироваться django-celery
в ваших настройках, а затем вы можете сделать что-то вроде этого:
from celery import task
from celery.decorators import periodic_task
from celery.task.schedules import crontab
from celery.utils.log import get_task_logger
@periodic_task(run_every=crontab(minute="0", hour="23"))
def do_every_midnight():
#your code
Я не уверен, что это будет полезно для кого-либо, так как я должен был предоставить другим пользователям системы планировать задания, не давая им доступ к фактическому планировщику задач сервера(windows), я создал это многоразовое приложение.
обратите внимание, что пользователи имеют доступ к одной общей папке на сервере, где они могут создавать необходимые команды/задачи/.Bat-файл. Эта задача может быть запланирована с помощью этого приложения.
название приложения Django_Windows_Scheduler
более современным решением (по сравнению с сельдереем) является Django Q: https://django-q.readthedocs.io/en/latest/index.html
Он имеет большую документацию и легко grok. Поддержка Windows отсутствует, поскольку Windows не поддерживает процесс разветвления. Но он отлично работает, если вы создаете среду разработки с помощью подсистемы Windows для Linux.
вы обязательно должны проверить django-q! Он не требует дополнительной настройки и, вполне возможно, имеет все необходимое для решения любых производственных проблем в коммерческих проектах.
он активно развивается и очень хорошо интегрируется с django, django ORM, mongo, redis. Вот моя конфигурация:
# django-q
# -------------------------------------------------------------------------
# See: http://django-q.readthedocs.io/en/latest/configure.html
Q_CLUSTER = {
# Match recommended settings from docs.
'name': 'DjangoORM',
'workers': 4,
'queue_limit': 50,
'bulk': 10,
'orm': 'default',
# Custom Settings
# ---------------
# Limit the amount of successful tasks saved to Django.
'save_limit': 10000,
# See https://github.com/Koed00/django-q/issues/110.
'catch_up': False,
# Number of seconds a worker can spend on a task before it's terminated.
'timeout': 60 * 5,
# Number of seconds a broker will wait for a cluster to finish a task before presenting it again. This needs to be
# longer than `timeout`, otherwise the same task will be processed multiple times.
'retry': 60 * 6,
# Whether to force all async() calls to be run with sync=True (making them synchronous).
'sync': False,
# Redirect worker exceptions directly to Sentry error reporter.
'error_reporter': {
'sentry': RAVEN_CONFIG,
},
}
Если вы хотите что-то больше надежный чем сельдерей попробуй TaskHawk, который построен на вершине AWS SQS / SNS.