Деплой и масштабирование Telegram-бота на VPS: мониторинг, Docker-инфраструктура, обход банов yt-dlp

Реальный кейс: держим весь стек Telegram-бота «Скачай просто» (бот, воркер очередей, мини-веб-админка, Redis) на одной VPS с 1 CPU и 1.8 GB RAM через Docker Compose. Делюсь, что уже наступило на грабли и как решали.

Инфраструктура: три отдельных Docker-образа — bot (обработка сообщений Telegram), worker (тяжёлая работа: скачивание и конвертация видео через yt-dlp), miniapi (веб-админка для мониторинга и управления). Задачи между bot и worker идут через очередь (Celery-стиль). Разделение критично на слабом железе — тяжёлая обработка видео не блокирует ответы бота в чате.

Грабля №1 — порядок деплоя при изменении сигнатуры задачи. Если worker и bot временно работают на разных версиях кода (а при поочерёдном деплое это неизбежные несколько секунд), и новый bot вызывает задачу с параметром, которого старый worker не знает — задача падает ещё до попытки повтора. Решение — правило «новые параметры задач только как keyword с default» + строгий порядок деплоя: сначала worker, потом bot.

Грабля №2 — Docker build cache незаметно съедает диск. При каждой пересборке образов кэш слоёв растёт, и на маленьком диске VPS это быстро упирается в лимит — у нас конкретно build cache вырос до 7+ GB на сервере, где вообще весь диск 40 GB. Разовая чистка (docker builder prune) освобождает большую часть, но без периодической чистки проблема возвращается.

Грабля №3 — обход изменяющейся антибот-защиты источников (не самого сервера, а площадок типа YouTube). YouTube требует выполнения JS-кода на стороне бэкенда для расшифровки ссылок на видео — без встроенного JS-рантайма (используем Deno прямо в докер-образе) часть скачиваний просто переставала работать. Это не про "взлом" площадки, а про то, что yt-dlp честно документирует такое требование, и его нужно удовлетворить на своей стороне.

Мониторинг на таком слабом железе — обязателен, не опция. Фоновая проверка здоровья каждые 5 минут (APScheduler), алерты с severity уровнями прямо в Telegram владельцу при аномалиях (резкий рост ошибок скачивания, диск на пороге, краши процесса). Без этого на 1 CPU/1.8GB любая деградация замечается только по жалобам пользователей, а не проактивно.

Из практических советов, если кто-то повторяет похожий сетап на минимальной VPS: закладывайте здоровый мониторинг сразу, а не когда «прижмёт» — это дешевле по времени, чем разбор инцидента постфактум; и не забывайте про Docker build cache — на маленьком диске это реальный, а не гипотетический риск.

Бот (как иллюстрация конечного результата): @Saver_robot_bot