Демонизация

Большинство дистрибутивов Linux в наши дни используют systemd для управления жизненным циклом системных и пользовательских сервисов.

Вы можете проверить, использует ли ваш дистрибутив Linux systemd, набрав:

$ systemd --version
systemd 237
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid

Если у вас есть вывод, подобный приведенному выше, обратитесь за руководством к our systemd documentation.

Однако скрипт init.d должен работать и в этих дистрибутивах Linux, поскольку systemd предоставляет уровень совместимости systemd-sysv, который автоматически генерирует сервисы из скриптов init.d, которые мы предоставляем.

Если вы упаковываете Celery для нескольких дистрибутивов Linux, и некоторые из них не поддерживают systemd, а также для других Unix-систем, вы можете обратиться к our init.d documentation.

Общие init-скрипты

См. каталог extra/generic-init.d/ дистрибутива Celery.

Этот каталог содержит общие bash init-скрипты для программы celery worker, они должны работать на Linux, FreeBSD, OpenBSD и других Unix-подобных платформах.

Начальный скрипт: celeryd

Использование:

/etc/init.d/celeryd {start|stop|restart|status}.

Конфигурационный файл:

/etc/default/celeryd

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

Сценарий демонизации конфигурируется файлом /etc/default/celeryd. Это сценарий оболочки (sh), в который можно добавить переменные окружения, подобные приведенным ниже параметрам конфигурации. Чтобы добавить реальные переменные окружения, влияющие на рабочий, вы должны также экспортировать их (например, export DISPLAY=":0")

Требуются привилегии суперпользователя

init-скрипты может использовать только root, а файл конфигурации оболочки также должен принадлежать root.

Непривилегированным пользователям не нужно использовать init-скрипт, вместо этого они могут воспользоваться утилитой celery multi (или celery worker --detach):

$ celery -A proj multi start worker1 \
    --pidfile="$HOME/run/celery/%n.pid" \
    --logfile="$HOME/log/celery/%n%I.log"

$ celery -A proj multi restart worker1 \
    --logfile="$HOME/log/celery/%n%I.log" \
    --pidfile="$HOME/run/celery/%n.pid

$ celery multi stopwait worker1 --pidfile="$HOME/run/celery/%n.pid"

Пример конфигурации

Это пример конфигурации для проекта Python.

/etc/default/celeryd:

# Names of nodes to start
#   most people will only start one node:
CELERYD_NODES="worker1"
#   but you can also start multiple and configure settings
#   for each in CELERYD_OPTS
#CELERYD_NODES="worker1 worker2 worker3"
#   alternatively, you can specify the number of nodes to start:
#CELERYD_NODES=10

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/usr/local/bin/celery"
#CELERY_BIN="/virtualenvs/def/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="proj"
# or fully qualified:
#CELERY_APP="proj.tasks:app"

# Where to chdir at start.
CELERYD_CHDIR="/opt/Myproject/"

# Extra command-line arguments to the worker
CELERYD_OPTS="--time-limit=300 --concurrency=8"
# Configure node-specific settings by appending node name to arguments:
#CELERYD_OPTS="--time-limit=300 -c 8 -c:worker2 4 -c:worker3 2 -Ofair:worker1"

# Set logging level to DEBUG
#CELERYD_LOG_LEVEL="DEBUG"

# %n will be replaced with the first part of the nodename.
CELERYD_LOG_FILE="/var/log/celery/%n%I.log"
CELERYD_PID_FILE="/var/run/celery/%n.pid"

# Workers should run as an unprivileged user.
#   You need to create this user manually (or you can choose
#   a user/group combination that already exists (e.g., nobody).
CELERYD_USER="celery"
CELERYD_GROUP="celery"

# If enabled pid and log directories will be created if missing,
# and owned by the userid/group configured.
CELERY_CREATE_DIRS=1

Использование оболочки для входа в систему

Вы можете унаследовать окружение CELERYD_USER, используя оболочку входа в систему:

CELERYD_SU_ARGS="-l"

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

Пример конфигурации Django

Теперь пользователи Django используют точно такой же шаблон, как и выше, но убедитесь, что модуль, определяющий ваш экземпляр приложения Celery, также устанавливает значение по умолчанию для DJANGO_SETTINGS_MODULE, как показано в примере проекта Django в Первые шаги в работе с Django.

Доступные опции

  • CELERY_APP

    Экземпляр приложения для использования (значение для аргумента --app).

  • CELERY_BIN

    Абсолютный или относительный путь к программе celery. Примеры:

    • celery

    • /usr/local/bin/celery

    • /virtualenvs/proj/bin/celery

    • /virtualenvs/proj/bin/python -m celery

  • CELERYD_NODES

    Список имен узлов для запуска (разделенных пробелом).

  • CELERYD_OPTS

    Дополнительные аргументы командной строки для рабочего, список см. в celery worker –help. Здесь также поддерживается расширенный синтаксис, используемый multi для настройки параметров отдельных узлов. Смотрите celery multi –help для некоторых примеров конфигурации нескольких узлов.

  • CELERYD_CHDIR

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

  • CELERYD_PID_FILE

    Полный путь к файлу PID. По умолчанию это /var/run/celery/%n.pid

  • CELERYD_LOG_FILE

    Полный путь к файлу рабочего журнала. По умолчанию это /var/log/celery/%n%I.log Примечание: Использование %I важно при использовании пула prefork, так как использование несколькими процессами одного и того же файла журнала приведет к возникновению условий гонки.

  • CELERYD_LOG_LEVEL

    Уровень журнала рабочего процесса. По умолчанию - INFO.

  • CELERYD_USER

    Пользователь, от имени которого будет запущен рабочий. По умолчанию это текущий пользователь.

  • CELERYD_GROUP

    Группа, от имени которой будет запущен рабочий. По умолчанию это текущий пользователь.

  • CELERY_CREATE_DIRS

    Всегда создавать каталоги (каталог журнала и каталог pid-файла). По умолчанию создаются только каталоги, если не задан пользовательский logfile/pidfile.

  • CELERY_CREATE_RUNDIR

    Всегда создавать каталог pidfile. По умолчанию включается только в том случае, если не задано пользовательское расположение pidfile.

  • CELERY_CREATE_LOGDIR

    Всегда создавать каталог лог-файла. По умолчанию включается только в том случае, если не задано пользовательское расположение лог-файла.

Начальный скрипт: celerybeat

Использование:

/etc/init.d/celerybeat {start|stop|restart}.

Конфигурационный файл:

/etc/default/celerybeat или /etc/default/celeryd.

Пример конфигурации

Это пример конфигурации для проекта Python:

/etc/default/celerybeat:

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/usr/local/bin/celery"
#CELERY_BIN="/virtualenvs/def/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="proj"
# or fully qualified:
#CELERY_APP="proj.tasks:app"

# Where to chdir at start.
CELERYBEAT_CHDIR="/opt/Myproject/"

# Extra arguments to celerybeat
CELERYBEAT_OPTS="--schedule=/var/run/celery/celerybeat-schedule"

Пример конфигурации Django

Вы должны использовать тот же шаблон, что и выше, но убедитесь, что переменная DJANGO_SETTINGS_MODULE установлена (и экспортирована), и что CELERYD_CHDIR установлена на каталог проектов:

export DJANGO_SETTINGS_MODULE="settings"

CELERYD_CHDIR="/opt/MyProject"

Доступные опции

  • CELERY_APP

    Экземпляр приложения для использования (значение для аргумента --app).

  • CELERYBEAT_OPTS

    Дополнительные аргументы к celery beat, список доступных опций см. в celery beat --help.

  • CELERYBEAT_PID_FILE

    Полный путь к файлу PID. По умолчанию /var/run/celeryd.pid.

  • CELERYBEAT_LOG_FILE

    Полный путь к файлу журнала. По умолчанию /var/log/celeryd.log.

  • CELERYBEAT_LOG_LEVEL

    Используемый уровень журнала. По умолчанию INFO.

  • CELERYBEAT_USER

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

  • CELERYBEAT_GROUP

    Группа, от имени которой запускается beat. По умолчанию это текущий пользователь.

  • CELERY_CREATE_DIRS

    Всегда создавать каталоги (каталог журнала и каталог pid-файла). По умолчанию создаются только каталоги, если не задан пользовательский logfile/pidfile.

  • CELERY_CREATE_RUNDIR

    Всегда создавать каталог pidfile. По умолчанию включается только в том случае, если не задано пользовательское расположение pidfile.

  • CELERY_CREATE_LOGDIR

    Всегда создавать каталог лог-файла. По умолчанию включается только в том случае, если не задано пользовательское расположение лог-файла.

Устранение неполадок

Если вы не можете заставить init-скрипты работать, попробуйте запустить их в режиме verbose:

# sh -x /etc/init.d/celeryd start

Это может дать подсказки о том, почему сервис не запускается.

Если рабочий запускается с сообщением «OK «, но почти сразу после этого завершает работу, а в лог-файле нет никаких доказательств, то, вероятно, произошла ошибка, но поскольку стандартные выходы демонов уже закрыты, вы нигде не сможете их увидеть. В этой ситуации вы можете использовать переменную окружения C_FAKEFORK, чтобы пропустить этап демонизации:

# C_FAKEFORK=1 sh -x /etc/init.d/celeryd start

и теперь вы должны увидеть ошибки.

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

Использование systemd

Использование:

systemctl {start|stop|restart|status} celery.service.

Конфигурационный файл:

/etc/conf.d/celery

Сервисный файл: celery.service

Это пример файла systemd:

/etc/systemd/system/celery.service:

[Unit]
Description=Celery Service
After=network.target

[Service]
Type=forking
User=celery
Group=celery
EnvironmentFile=/etc/conf.d/celery
WorkingDirectory=/opt/celery
ExecStart=/bin/sh -c '${CELERY_BIN} -A $CELERY_APP multi start $CELERYD_NODES \
    --pidfile=${CELERYD_PID_FILE} --logfile=${CELERYD_LOG_FILE} \
    --loglevel="${CELERYD_LOG_LEVEL}" $CELERYD_OPTS'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait $CELERYD_NODES \
    --pidfile=${CELERYD_PID_FILE} --loglevel="${CELERYD_LOG_LEVEL}"'
ExecReload=/bin/sh -c '${CELERY_BIN} -A $CELERY_APP multi restart $CELERYD_NODES \
    --pidfile=${CELERYD_PID_FILE} --logfile=${CELERYD_LOG_FILE} \
    --loglevel="${CELERYD_LOG_LEVEL}" $CELERYD_OPTS'
Restart=always

[Install]
WantedBy=multi-user.target

После того, как вы поместили этот файл в /etc/systemd/system, вы должны выполнить systemctl daemon-reload для того, чтобы Systemd подтвердила этот файл. Вы также должны выполнять эту команду каждый раз, когда изменяете его. Используйте systemctl enable celery.service, если вы хотите, чтобы служба celery автоматически запускалась при (повторной) загрузке системы.

Опционально вы можете указать дополнительные зависимости для сервиса celery: например, если вы используете RabbitMQ в качестве брокера, вы можете указать rabbitmq-server.service в обоих After= и Requires= в [Unit] systemd section.

Чтобы настроить пользователя, группу, chdir измените параметры: User, Group и WorkingDirectory, определенные в /etc/systemd/system/celery.service.

Вы также можете использовать systemd-tmpfiles для создания рабочих каталогов (для журналов и pid).

файл:

/etc/tmpfiles.d/celery.conf

d /run/celery 0755 celery celery -
d /var/log/celery 0755 celery celery -

Пример конфигурации

Это пример конфигурации для проекта Python:

/etc/conf.d/celery:

# Name of nodes to start
# here we have a single node
CELERYD_NODES="w1"
# or we could have three nodes:
#CELERYD_NODES="w1 w2 w3"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/usr/local/bin/celery"
#CELERY_BIN="/virtualenvs/def/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="proj"
# or fully qualified:
#CELERY_APP="proj.tasks:app"

# How to call manage.py
CELERYD_MULTI="multi"

# Extra command-line arguments to the worker
CELERYD_OPTS="--time-limit=300 --concurrency=8"

# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/var/run/celery/%n.pid"
CELERYD_LOG_FILE="/var/log/celery/%n%I.log"
CELERYD_LOG_LEVEL="INFO"

# you may wish to add these options for Celery Beat
CELERYBEAT_PID_FILE="/var/run/celery/beat.pid"
CELERYBEAT_LOG_FILE="/var/log/celery/beat.log"

Файл службы: celerybeat.service

Это пример файла systemd для Celery Beat:

/etc/systemd/system/celerybeat.service:

[Unit]
Description=Celery Beat Service
After=network.target

[Service]
Type=simple
User=celery
Group=celery
EnvironmentFile=/etc/conf.d/celery
WorkingDirectory=/opt/celery
ExecStart=/bin/sh -c '${CELERY_BIN} -A ${CELERY_APP} beat  \
    --pidfile=${CELERYBEAT_PID_FILE} \
    --logfile=${CELERYBEAT_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL}'
Restart=always

[Install]
WantedBy=multi-user.target

После того, как вы поместили этот файл в /etc/systemd/system, вы должны выполнить systemctl daemon-reload для того, чтобы Systemd подтвердила этот файл. Вы также должны выполнять эту команду каждый раз, когда изменяете его. Используйте systemctl enable celerybeat.service, если вы хотите, чтобы служба celery beat автоматически запускалась при (повторной) загрузке системы.

Запуск рабочего с привилегиями суперпользователя (root)

Запуск рабочего с привилегиями суперпользователя - очень опасная практика. Всегда должно быть обходное решение, чтобы избежать запуска от имени root. Celery может выполнять произвольный код в сообщениях, сериализованных с помощью pickle - это опасно, особенно при запуске от имени root.

По умолчанию Celery не будет запускать рабочих от имени root. Соответствующее сообщение об ошибке может быть не видно в журналах, но может быть видно, если используется C_FAKEFORK.

Чтобы заставить Celery запускать рабочие программы от имени root, используйте C_FORCE_ROOT.

При запуске от имени root без C_FORCE_ROOT рабочий запустится с сообщением «OK «, но сразу после этого завершится без видимых ошибок. Эта проблема может возникнуть при запуске проекта в новой среде разработки или производства (по ошибке) от имени root.

supervisor

launchd (macOS)

Вернуться на верх