Django i Seler - ponowne ładowanie kodu do Selera po zmianie

Question

Jeśli podczas zmiany selera zostanie wprowadzona zmiana w parametrze tasks.py, czy istnieje mechanizm, za pomocą którego można ponownie załadować zaktualizowany kod? czy muszę zamknąć Celery w celu ponownego załadowania?

czytam seler miał --autoreload argument w starszych wersjach, ale nie mogę go znaleźć w aktualnej wersji:

celery: error: unrecognized arguments: --autoreload

Answer 1

Niestety nie działa --autoreload i jest to deprecated.

Można użyć funkcji nadzoru, która zapewnia watchmedo funkcję powłoki w celu wykonywania działań na podstawie zdarzeń plików.

pip install watchdog 

można rozpocząć pracownikowi

watchmedo auto-restart -- celery worker -l info -A foo 

Domyślnie będzie oglądać do wszystkich plików w bieżącym katalogu. Można je zmienić, przekazując odpowiednie parametry.

watchmedo auto-restart -d . -p '*.py' -- celery worker -l info -A foo 

Jeśli używasz django i nie chcesz polegać na systemie nadzoru, istnieje prosta sztuczka, aby to osiągnąć. Django ma narzędzie autoreload, które jest używane przez runserver do restartowania serwera WSGI po zmianie kodu.

Ta sama funkcja może zostać wykorzystana do przeładowania pracowników selera. Utwórz oddzielne polecenie zarządzania zwane selerem. Napisz funkcję, która zabije istniejącego pracownika i uruchom nowego pracownika. Teraz zaczep tę funkcję, aby automatycznie ładować w następujący sposób.

import shlex 
import subprocess 

from django.core.management.base import BaseCommand 
from django.utils import autoreload 


def restart_celery(): 
    cmd = 'pkill celery' 
    subprocess.call(shlex.split(cmd)) 
    cmd = 'celery worker -l info -A foo' 
    subprocess.call(shlex.split(cmd)) 


class Command(BaseCommand): 

    def handle(self, *args, **options): 
     print('Starting celery worker with autoreload...') 
     autoreload.main(restart_celery) 

Teraz można uruchomić pracownika seler python manage.py celery które autoreload gdy zmiany kodzie.

Jest to wyłącznie w celach programistycznych i nie należy go używać w produkcji.

Answer 2

Można spróbować SIGHUP na proces roboczy dominująca ponownym uruchomieniu pracownika , ale nie jestem pewien, czy odbiera nowe zadania. Warto strzelić, pomyśleć :)