worker-redis

Background worker с очередью на Redis. Используется в уроке 6.11 и в разделе 09.

Что демонстрирует

• graceful shutdown worker'а: текущая задача дообрабатывается, новые не берутся;
• blpop с таймаутом — позволяет периодически проверять флаг завершения;
• ожидание готовности Redis в коде: depends_on гарантирует запуск, но не готовность;
• stop_grace_period больше длительности задачи;
• healthcheck у Redis и condition: service_healthy у worker'а;
• лимит памяти через deploy.resources.

Запуск

docker compose up -d
docker compose logs -f worker

В другом терминале наполните очередь:

docker compose exec worker python producer.py 5 2

В логах worker'а видно последовательную обработку задач.

Ключевая проверка: graceful shutdown

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

docker compose exec worker python producer.py 3 5
sleep 2
time docker compose stop worker
docker compose logs worker | tail -5

Ожидается:

задача 1: начата
получен SIGTERM — завершаю после текущей задачи
задача 1: завершена
остановлен штатно, обработано задач: 1

Worker дообработал текущую задачу и вышел с кодом 0. Задачи 2 и 3 остались в очереди — они не потеряны:

docker compose exec redis redis-cli llen tasks

Запустите worker снова — он их заберёт:

docker compose start worker
docker compose logs -f worker

Что было бы без обработчика

Без signal.signal(SIGTERM, ...) worker является PID 1 и проигнорирует сигнал. Через 10 секунд Docker пошлёт SIGKILL, задача оборвётся на середине, exit code будет 137. Механизм разбирается в уроке 4.4.

Проверка зависимости по готовности

docker compose down
docker compose up -d
docker compose logs worker | head -3

Worker не выводит предупреждений о недоступности Redis, потому что condition: service_healthy задержал его запуск до готовности базы.

Уборка

docker compose down -v
docker rmi worker-redis-worker 2>/dev/null