Введение: Ниша между Celery и Kubernetes

Привет, Хабр!

Если вы когда-нибудь сталкивались с задачей запуска сотен изолированных фоновых процессов на одном сервере (будь то парсеры для клиентов, торговые боты или обработчики данных в SaaS), то вы знаете, как быстро всё усложняется.

Можно, конечно, вручную поднимать Docker-контейнеры и писать костыли для мониторинга. Можно развернуть полноценный Kubernetes, но для одной ноды это часто — оверкилл, требующий отдельного администратора. Можно использовать Celery, но он управляет задачами, а не контейнерами, и изоляция на уровне процессов — это не тоже самое, что изоляция на уровне контейнеров.

Мы столкнулись с этой болью и написали инструмент, который закрывает этот пробел. Встречайте: RedTailFox — легковесный оркестратор на Python, который управляет Docker-контейнерами с вашими воркерами на одном сервере. Он сам решает, когда поднять новый контейнер, сам следит за здоровьем слотов и сам себя чинит.

1. Почему RedTailFox?

Проект родился из прагматичных потребностей:

  • Нужно много изолированных воркеров. Например, под каждого клиента свой процесс с его конфигом.

  • Не хочется платить DevOps-инженеру только за то, чтобы следить за этой "фермой" контейнеров.

  • Хочется, чтобы система была самовосстанавливающейся. Упал контейнер? Остановился слот? Система должна перезапустить их без нашего участия.

  • Никакого YAML-программирования. Вся конфигурация — через переменные окружения и Python-словари. Просто и понятно.

RedTailFox — это ровно тот слой оркестрации, который нужен, когда Kubernetes слишком "жирный", а Celery не умеет управлять контейнерами.

2. Как это устроено (Архитектура)

Система состоит из трёх основных компонентов, которые общаются через Redis. Вот как выглядит жизненный цикл задачи:

  • Менеджер (manager.py): Центральный мозг. Он висит в цикле, читает задачи из Redis (manager_tasks) и принимает решения. Если есть свободный слот в уже запущенном контейнере — назначает задачу туда. Если слотов нет — через docker_utils.py запускает новый Docker-контейнер с воркером.

  • Воркер (worker.py): Живет внутри каждого Docker-контейнера. Он получает команду "start" от менеджера через Redis-канал и запускает у себя слот с задачей. Каждые 3 секунды он пишет heartbeat в Redis, сообщая, что он жив и занят.

  • Монитор (monitor.py): Санитар системы. Каждые 10 секунд он сканирует heartbeat'ы в Redis. Если видит, что какой-то контейнер или слот "молчит" дольше положенного (или находит контейнер-зомби, который есть в Docker, но не зарегистрирован в Redis), он отправляет команду на перезапуск в очередь менеджера.

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

3. Возможности, которые мы заложили

  • Умные слоты: Внутри одного контейнера можно запустить несколько слотов-воркеров (настраивается через MAX_SLOTS_PER_CONTAINER). Менеджер распределяет задачи по слотам оптимальным образом.

  • Автомасштабирование: Как только все слоты во всех контейнерах заняты, менеджер автоматически поднимает новый Docker-контейнер.

  • Автовосстановление (Self-healing): Монитор перезапускает упавшие слоты или целые контейнеры без вашего участия.

  • Graceful Shutdown: Воркеры умеют корректно завершаться, отписываясь от менеджера, чтобы тот не ждал ответа от мертвого слота.

  • Мониторинг (HeadBear): Встроенная легкая система метрик. Можно смотреть, какие слоты запущены, как давно они активны.

  • Конфигурация без YAML: Всё хранится либо в переменных окружения, либо в Redis. Запустил контейнер — он уже знает свою конфигурацию.

4. Быстрый старт за 5 минут

Давайте сразу к делу. Попробовать RedTailFox очень просто. Всё, что нужно — это Docker, Redis и Python.

  1. Клонируем и ставим зависимости:

    bash

git clone https://github.com/Dark-F0X/RedTailFox
cd RedTailFox
pip install -r requirements.txt
cp .env.example .env
# Отредактируйте .env, указав ваш Redis

Собираем образ воркера:

bash

docker build -t rtf-worker:latest -f worker/Dockerfile .

Запускаем менеджера и монитор (в двух разных терминалах):

bash

python manager/main.py
# В другом терминале
python monitor/monitor.py

Отправляем первую задачу (например, из Python-скрипта):

python

import redis, json
r = redis.Redis(host='localhost', port=6379)
task = {
    "command": "start",
    "slot_id": 1,
    "config": {
        "job": {
            "name": "my_first_scraper",
            "interval": 300
        }
    }
}
r.lpush("manager_tasks", json.dumps(task))
print("Задача ушла!")

Через несколько секунд вы увидите, как менеджер запустит Docker-контейнер, а воркер внутри него начнет выполнять задачу. Всё работает!

5. Где это пригодится?

Мы протестировали RedTailFox на реальных задачах и подтверждаем: на одном среднем сервере можно запустить более 1000 изолированных воркеров. Это открывает широкий спектр применений:

  • SaaS-платформы: Каждому клиенту — свой изолированный воркер для обработки его данных, интеграций или отчетов.

  • Парсинг и мониторинг: Сотни парсеров для разных сайтов или API, каждый со своими аккаунтами и прокси.

  • Торговые боты: Запуск множества стратегий для разных инструментов или счетов.

  • Фоновые джобы: Любые фоновые задачи, требующие строгой изоляции друг от друга.

Заключение и планы

RedTailFox — это не замена Kubernetes. Это инструмент для своей, четко очерченной задачи: простая и надежная оркестрация контейнеризированных воркеров на одном сервере.

Проект молодой (первый релиз — буквально вчера!), и мы активно развиваем его. В ближайших планах:

  • Интеграция с Prometheus для сбора метрик.

  • Поддержка нескольких нод (кластеризация).

  • Больше тестов и примеров на разных языках.

Мы ищем единомышленников! Если у вас есть идеи по улучшению, или вы хотите помочь с интеграционными тестами, документацией или новым функционалом — заходите к нам на GitHub, создавайте Issue или пишите в Telegram.

Ссылки:

Сделано с ? и любовью к Python для инженеров, которые ценят своё время.

Комментарии (11)


  1. huder
    20.02.2026 19:27

    Навайбкодили?


    1. Dark_bear Автор
      20.02.2026 19:27

      Написали проект. Решили поделиться данной технологией возможно кому- то пригодиться


  1. kenoma
    20.02.2026 19:27

    Hashicorp Nomad


    1. dyadyaSerezha
      20.02.2026 19:27

      Или Docker Compose?

      И кстати, интересно, какие требования к сервису явно говорят, что нужен отдельный процесс для каждого клиента? Чистое любопытство. Не вообще, а именно у автора.


  1. baldr
    20.02.2026 19:27

    Скорее что-то типа AirFlow, только без минусов с жёстко пришитыми DAGами и неоптимального запуска?

    Я тоже сделал что-то такое, но всё никак не соберусь причесать и рассказать.


  1. ashumkin
    20.02.2026 19:27

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

    А вы же знали про minikube? Правда ж, знали?

    Проект родился из прагматичных потребностей:

    Просто, кажется вы зарубили k8s/миникуб, который всем им удовлетворяет, просто потому что посчитали его сложным, и почему-то считаете (из написанного я делаю такой вывод) конфигурирование через энвы гораздо проще, чем ямлик написать, хотя принципиальной, как по мне, разницы нет: и то, и то - текст


  1. phikus
    20.02.2026 19:27

    Разве systemd это всё не может делать?


  1. devhashiops
    20.02.2026 19:27

    Прочитал статью и посмотрел код в репозитории. У меня один вопрос: почему вам не стыдно? Вы пишиете:
    > любовью к Python для инженеров, которые ценят своё время
    Но при этом делаете ровно наоборот, вместо того, чтобы подобрать подходящий инструмент под ваши задачи, вы тратите кучу времени на вайбкодинг своего велосипеда, которым кроме вас никто и никогда пользоваться не будет.
    Зачем тут тег DevOps? Уберите его и поставьте тег VibeCoding


  1. myshkin_does_it
    20.02.2026 19:27

    что такое слоты? как у ввс устроен запуск нескольких воркеров в одном контейнере?

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


  1. nsmcan
    20.02.2026 19:27

    Никакого YAML-программирования. Вся конфигурация — через переменные окружения и Python-словари. Просто и понятно.

    Ладно, переменные окружения для секретов - это ок. Но чем питон-словари проще YAML? Может уж тогда совсем JSON использовать

    И что вы там в YAML можете напрограммировать и, главное, зачем?


  1. kozzztik
    20.02.2026 19:27

    Похоже вы изобрели gunicorn.