# Фоновые обработчики Не каждый сервер обслуживает HTTP. Потребители очередей, реконсилеры, cron-опросные циклы и другие фоновые рабочие нагрузки не слушают порт — запустите их в **рабочем режиме**, установив порт контейнера в `0`. ## Что меняет рабочий режим Когда `containerPort=0`, платформа: - **Пропускает внедрение `PORT`** — обработчик не привязывается нигде. - **Пропускает проверку доступности порта** — нет спама `app port X unreachable` в логах и ложноположительного статуса "unhealthy". - **Пропускает `EXPOSE`** в синтезируемом Dockerfile. - **Пропускает регистрацию маршрута балансировщика** — ничего не обслуживается. (Сгенерированный домен `*.onlizard.com` может всё ещё отображаться в сервисе, но он не будет отвечать.) ## Включить рабочий режим Три эквивалентных способа: ```bash # New upload-source worker lizard up --port 0 # Flip an existing service lizard port 0 --service worker # Via the config:apply path lizard service set worker --set containerPort=0 ``` Рабочий режим — жёсткий переключатель — для вступления в силу изменения порта требуется повторный деплой. ## Проверить текущий порт ```bash lizard port --service worker ``` Выводит текущий порт контейнера или `worker mode`, когда он `0`. ## Когда *не* стоит использовать рабочий режим Не используйте рабочий режим для обычного HTTP-сервиса, который просто медленно запускается. Рабочий режим полностью отключает проверку доступности, поэтому он **скроет** ошибки вроде "the listener never came up". Если ваш сервис предназначен для обслуживания трафика, оставьте реальный порт и исправьте запуск. ## Запуск потребителя очереди Используйте [пример redis-worker](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/redis-worker). Он перемещает задание из списка ожидающих в список обрабатываемых, сохраняет его результат в верхнем регистре и подтверждает задание в транзакции Redis. Оставьте одну реплику: восстановление при запуске предполагает одного потребителя. Пример использует Python 3.13 и redis-py 6.4.0. Из директории с его Dockerfile: ```bash lizard init --name queue-example lizard add --service worker lizard add redis lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker lizard up --service worker --port 0 ``` Выполните вход с помощью `lizard login`, если команда сообщает, что требуется аутентификация. Используйте фактическое имя базы данных, если оно не `redis`. Держите ссылку в кавычках. Установите её перед загрузкой приложения. В macOS с Lizard CLI 0.3.92 добавьте префикс `lizard up` с `COPYFILE_DISABLE=1`, чтобы исключить метаданные AppleDouble. Проверьте финальное событие деплоя, затем проверьте обработчик: ```bash lizard port --service worker lizard logs --service worker --json lizard ssh --service worker -- python jobs.py enqueue first-job lizard ssh --service worker -- python jobs.py result first-job ``` Процесс выводит `Queue worker ready`. Если хвост лога пуст, переходите к проверке задания ниже; в [результатах тестов](https://lizard.build/ru/docs/guides/validation) зафиксирован наблюдаемый лимит логирования. Команда результата ждёт до 30 секунд и выводит `{"id": "first-job", "result": "HELLO"}`. Само по себе запущенный процесс не доказывает, что он может потреблять задания. Managed Redis доступен изнутри сервиса; CLI-команде не требуется, чтобы ваш ноутбук достигал его приватного адреса. ## Проверка перезапуска Для этого тестового сервиса перезапустите обработчик и отправьте ещё одно задание: ```bash lizard restart --service worker lizard ssh --service worker -- python jobs.py result first-job lizard ssh --service worker -- python jobs.py enqueue after-restart lizard ssh --service worker -- python jobs.py result after-restart ``` Дождитесь возвращения сервиса в `running` в `lizard ps --json`, если SSH ещё недоступен. Оба результата должны быть `HELLO`. Первый результат живёт в Redis, поэтому перезапуск обработчика не удаляет его. При запуске единственный потребитель возвращает незавершённые записи обработки в список ожидающих. Этот демо принимает только JSON-задания, созданные `jobs.py`. Он не реализует очередь мёртвых писем, валидацию для недоверенных производителей или exactly-once внешние побочные эффекты. Для платежей, email или других эффектов используйте проверенную библиотеку очередей и идемпотентные обработчики. Надёжность и бэкап Redis отделены от поведения перезапуска обработчика; см. [хранилище и восстановление](https://lizard.build/ru/docs/platform/storage-and-recovery). ## Устранение неполадок | Симптом | Проверка | |---|---| | Сервис не найден | Выполните `lizard add --service worker` после создания проекта. | | Нет `Queue worker ready` | Проверьте `REDIS_URL` сервиса, готовность аддона и ошибки подключения. Никогда не печатайте строку подключения. | | Обработчик ожидает HTTP-порт | Установите `containerPort=0`; изменение на работающем сервисе требует повторного деплоя. | | Нет результата через 30 секунд | Прочитайте логи обработчика и проверьте ID задания. Этот пример принимает задания только от своего `jobs.py`. | | Дублирующиеся эффекты | Повторная попытка может выполнить работу снова. Этот пример сохраняет результат по ID задания; внешние эффекты требуют свою идемпотентность. | ## См. также - [`lizard port`](https://lizard.build/ru/docs/cli/port) — показать или изменить порт контейнера сервиса. - [Сервис никогда не становится здоровым](https://lizard.build/ru/docs/deploy/troubleshooting/service-never-healthy) — самая частая ошибка конфигурации рабочего режима. - [Управляемые аддоны](https://lizard.build/ru/docs/addons) — Redis, Postgres и S3 для стейтфул-нагрузок. - [Хостинг Python-приложений](https://lizard.build/blog/python-app-hosting#deploying-django) — Celery-обработчик — тот же образ с другой командой и без HTTP-порта. См. [результаты сценарийных тестов](https://lizard.build/ru/docs/guides/validation) для проверенных версий, облачных результатов и оставшихся ограничений.