Что такое надежный способ выполнения длительных задач/партий в Django?

Question

У меня есть приложение Django, предназначенное для работы на виртуальных виртуальных машинах Virtual LAN. Основным пользователем будет опытный ИТ-конечный пользователь, а не системный администратор.

Часть задания этого приложения заключается в подключении к внешним базам данных в локальной сети, выполнении некоторых пакетов python для этих баз данных и сохранении результатов в локальном db. Затем пользователь может исследовать системы, используя страницы Django.

Время выполнения для партий не так долго, но работает до минут, десятков минут, а не секунд. Частота запуска в лучшем случае нечастая, я думаю, вы могли бы провести дни, не нуждаясь в обновлении.

Это не обычный случай использования сельдерея длинных задач, который в конечном итоге приведет результаты обратно в веб-интерфейс через ajax и/или опрос. Он больше похож на случайное использование Dev разработчиками команд django-admin, но на этот раз предназначено для конечного пользователя.

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

До тех пор, пока партии не будут выполнены для данного db, приложение действительно не пригодно для использования. Вы можете получить доступ к его страницам, но многие функции будут недоступны.

Очень важно, с точки зрения поддержки, что партии остаются легко управляемыми во все времена. Сбрасывание на виртуальные машины SSH, вероятно, потребует частого удержания рук, что было бы неплохо - лучше всего, чтобы вы могли запускать их с веб-страниц Django.

То, что я в настоящее время:

Каждая партия находится в своем собственном сценарии.

1. Я могу запустить его в командной строке (через если __name__ == "главный":).

2. Пакеты также подключаются как задачи сельдерея и отлично работают.

3. Учитывая, что я написал их, было бы относительно легко разрешить запуск их из вызовов подпроцесса в Python. Я на самом деле не посмотрел на него, но я полагаю, что мог бы сделать их и в командах django-admin.

4. Пакеты уже имеют свои рудиментарные проверки состояния. Например, они могут просматривать рассчитанные данные и сообщать, были ли они запущены и отображены это на страницах Django, без необходимости просмотра бэкэнда статуса задачи сельдерея.

5. Сами партии относительно прочные, и я могу сделать их более такими. Речь идет об их механизме запуска.

Что не так здорово.

В среде Mac dev я считаю, что стеллаж из сельдерея/celerycam/rabbitmq несколько нестабилен. Похоже, что когда-то какой-то демон rabbitmqs запускается в режиме CPU/RAM, а затем его нужно прекратить. Это сильно смущает процессы сельдерея, и я считаю, что мне нужно убить -9 различных задач и перезапустить их вручную. Иногда сельдерей все еще работает, но celerycam не обновляет никаких задач.Некоторые из этих проблем могут быть специфичными для OSX или могут быть связаны с тем, что флаг DEBUG переключается на данный момент, о чем предупреждает сельдерей.

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

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

Учитывая, что это несколько выстрелов и забытых партий, мне интересно, если сельдерей не переборщит на этом этапе.

Некоторые опции я думал о:

1. написание/скрипт Python очистки оболочки, чтобы перезапустить RabbitMQ/сельдерей/celerycam и вообще сделать его более устойчивым. то есть все, что требуется, чтобы сделать сельдерей & все более стабильным. Я уже использовал psutil, чтобы выяснить, как работает кролик/сельдерей, и отображает их статус в Django.

2. Выполнение партий по подпроцессу вместо этого и избегать сельдерея. Как насчет команд django-admin здесь? Это имеет значение? Все еще нужно запускать с веб-страниц.

3. альтернативный менеджер задач/процессов для сельдерея с меньшей способностью, но также и менее подвижными частями?

4. не используется подпроцесс, но полагается на Python многопроцессорный модуль? Честно говоря, я понятия не имею, как это сравнивается с запусками через подпроцесс.

среда: Nginx, WSGI, убунту на VirtualBox, повар строить виртуальные машины.

Answer 1

Я не уверен, как ваша конфигурация сельдерея делает ее нестабильной, но звучит так, будто она по-прежнему подходит для вашей проблемы. Я использую redis как систему очередей, и он работает лучше, чем rabbitmq по собственному опыту. Может быть, вы сможете попробовать, если это улучшит ситуацию.

В противном случае просто используйте cron в качестве драйвера для выполнения периодических задач. Вы можете просто позволить ему периодически запускать скрипт и обновлять базу данных, ваш компонент пользовательского интерфейса будет опросить базу данных без конфликтов.