Практикум: единый жизненный цикл для HTTP и воркера¶
У сервиса отчётов есть HTTP-обработчик и периодическое фоновое задание. В one_lifecycle.py они используют один AppSpec и контейнер зависимостей. Режимы api, worker и all определяют, какие точки входа запускать. В разных процессах будут отдельные ресурсы с одинаковыми правилами инициализации.
report_store.py имитирует базу данных в памяти. Он записывает открытие ресурса, запуск и отмену отчётов, закрытие и выдаёт ошибку, если ресурс закрыли до завершения работы. run_roles.py проверяет три режима, ошибку прогрева, остановку во время прогрева и сбой обязательного воркера. Порядок событий проверяется через assert, а не по приблизительным замерам времени.
Фоновый обработчик сам ограничивает одну операцию секундой. DaemonEntrypoint не добавляет произвольной функции очередь с ограниченным временем завершения. В режиме all Host ждёт возврата из функции воркера и только затем снимает readiness.
Драйвер отправляет настоящие HTTP-запросы на localhost и останавливает сервис через Service.run(..., stop=event). Он работает на Windows и Linux, но не проверяет сигналы ОС или маршрутизацию Kubernetes. Для ручного запуска выполните one_lifecycle.py api с теми же зависимостями: сервер слушает 127.0.0.1:8080, сигналы обрабатывает run_sync.
Запустите из каталога docs/blog/lab/2026-09-07-one-lifecycle в копии репозитория: