Фоновые обработчики

Не каждый сервер обслуживает HTTP. Потребители очередей, реконсилеры, cron-опросные циклы и другие фоновые рабочие нагрузки не слушают порт — запустите их в рабочем режиме, установив порт контейнера в 0.

Что меняет рабочий режим

Когда containerPort=0, платформа:

• Пропускает внедрение PORT — обработчик не привязывается нигде.
• Пропускает проверку доступности порта — нет спама app port X unreachable в логах и ложноположительного статуса “unhealthy”.
• Пропускает EXPOSE в синтезируемом Dockerfile.
• Пропускает регистрацию маршрута балансировщика — ничего не обслуживается. (Сгенерированный домен *.onlizard.com может всё ещё отображаться в сервисе, но он не будет отвечать.)

Включить рабочий режим

Три эквивалентных способа:

# 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

Рабочий режим — жёсткий переключатель — для вступления в силу изменения порта требуется повторный деплой.

Проверить текущий порт

lizard port --service worker

Выводит текущий порт контейнера или worker mode, когда он 0.

Когда не стоит использовать рабочий режим

Не используйте рабочий режим для обычного HTTP-сервиса, который просто медленно запускается. Рабочий режим полностью отключает проверку доступности, поэтому он скроет ошибки вроде “the listener never came up”. Если ваш сервис предназначен для обслуживания трафика, оставьте реальный порт и исправьте запуск.

Запуск потребителя очереди

Используйте пример redis-worker. Он перемещает задание из списка ожидающих в список обрабатываемых, сохраняет его результат в верхнем регистре и подтверждает задание в транзакции Redis. Оставьте одну реплику: восстановление при запуске предполагает одного потребителя. Пример использует Python 3.13 и redis-py 6.4.0.

Из директории с его Dockerfile:

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.

Проверьте финальное событие деплоя, затем проверьте обработчик:

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. Если хвост лога пуст, переходите к проверке задания ниже; в результатах тестов зафиксирован наблюдаемый лимит логирования. Команда результата ждёт до 30 секунд и выводит {"id": "first-job", "result": "HELLO"}. Само по себе запущенный процесс не доказывает, что он может потреблять задания. Managed Redis доступен изнутри сервиса; CLI-команде не требуется, чтобы ваш ноутбук достигал его приватного адреса.

Проверка перезапуска

Для этого тестового сервиса перезапустите обработчик и отправьте ещё одно задание:

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 отделены от поведения перезапуска обработчика; см. хранилище и восстановление.

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

См. также

• lizard port — показать или изменить порт контейнера сервиса.
• Сервис никогда не становится здоровым — самая частая ошибка конфигурации рабочего режима.
• Управляемые аддоны — Redis, Postgres и S3 для стейтфул-нагрузок.
• Хостинг Python-приложений — Celery-обработчик — тот же образ с другой командой и без HTTP-порта.

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