Хватит тащить Kubernetes туда, где справятся три строчки в systemd

В 2022 году я чуть не лишился крупного клиента из-за собственной глупости. Клиенту нужно было простое решение: собирать новые лиды с немецкого сайта недвижимости и мгновенно пересылать их в Telegram-чат менеджеров. Работа копеечная, делов на вечер. Но я тогда был отравлен культом «правильной архитектуры». Я развернул Docker, прикрутил Celery, воткнул Redis для очередей и завернул всё это в красивую, как мне казалось, обертку. Гордился собой неимоверно.

Через две недели Redis тихо упал из-за нехватки памяти на дешевом сервере. Очередь забилась, контейнер завис, а система мониторинга, которую я поленился настроить нормально, промолчала. Клиент потерял сделку на 12 000 евро просто потому, что бот вовремя не прислал уведомление. Я помню тот холодный пот, когда читал его гневное сообщение в Slack. Именно тогда я понял: усложнение — это профессиональный грех.

Эра оверинжиниринга

Сегодня индустрия сошла с ума. Нам внушают, что для запуска банального скрипта, который раз в час проверяет почту или парсит API, нужен Kubernetes, Docker Swarm или как минимум тяжелый Airflow. Разработчики тратят гигабайты памяти и сотни долларов в месяц на инфраструктуру, которая просто проедает ресурсы вхолостую.

Давайте посчитаем. Один контейнер с Docker-окружением для Python-скрипта «ест» от 150 МБ оперативной памяти просто на старте. А если таких скриптов у вас десять? А если пятьдесят? Вы покупаете сервер за 40 долларов там, где хватило бы машинки за пять баксов. Это не инженерия, это расточительство.

Почему мы вернулись к истокам

В GuardLabs мы пишем и запускаем десятки скриптов для клиентов: от мониторинга цен до автоматической выписки платежных ваучеров и публикации контента. И мы делаем это без Docker. Вообще.

Наш выбор — чистый Python, systemd и cron на обычной виртуальной машине. Эта связка работает годами без единого сбоя. Когда вы запускаете автономные агенты на vps напрямую через системные службы, накладные расходы стремятся к нулю. Скрипт потребляет ровно столько, сколько нужно его коду — обычно около 15-30 МБ RAM. Никакой виртуализации сетевых мостов, никаких лишних слоев абстракции.

Для изоляции зависимостей мы используем обычные виртуальные окружения (venv). Один проект — одна папка — одно окружение. Этого более чем достаточно, чтобы библиотеки не конфликтовали между собой. Благодаря этому на одном копеечном сервере у нас уживается много ботов на одном сервере. Они не дерутся за ресурсы, не перегревают процессор и не требуют постоянного внимания системного администратора.

Как это устроено на практике

Вся магия держится на двух инструментах, которые встроены в любой дистрибутив Linux по умолчанию.

Первый — это systemd. Если вашему агенту нужно работать постоянно (например, слушать вебхуки или держать WebSocket-соединение с биржей), забудьте про бесконечные циклы `while True` в терминале под `screen`. Мы пишем простой конфигурационный файл службы. Выглядит он примерно так:

[Unit]
Description=Telegram Lead Bot
After=network.target

[Service]
Type=simple
User=botuser
WorkingDirectory=/home/botuser/apps/lead_bot
ExecStart=/home/botuser/apps/lead_bot/venv/bin/python main.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Всего три ключевые строчки решают 99% проблем стабильности. Директива `Restart=always` означает, что если ваш скрипт упадет из-за таймаута базы данных или кривого ответа от внешнего API, операционная система сама поднимет его через 5 секунд. Логи пишутся напрямую в systemd journal, их легко читать через обычный `journalctl`. Никаких сторонних библиотек для логирования, никаких раздутых файлов на диске, которые внезапно забивают всё свободное пространство.

Второй инструмент — cron. Если задачу нужно запускать периодически — например, раз в сутки проверять баланс или раз в час собирать статистику — systemd cron автоматизация работает безупречно. Запись в crontab запускает легковесный процесс, он делает свою работу за 10 секунд и полностью освобождает память. Никаких висящих в фоне Celery-воркеров, которые часами ждут у моря погоды и жрут ресурсы.

Почему это надежнее Docker

Docker — прекрасный инструмент для изоляции сложных веб-приложений с кучей зависимостей. Но для фоновых скриптов он часто становится точкой отказа. Сетевые мосты Docker могут зависнуть, демон Docker может упасть после обновления системы, а очистка неиспользуемых образов со временем забивает диск до нуля. Я проходил это лично, когда посреди ночи сервер ложился просто потому, что Docker забил диск своими логами и старыми слоями образов.

Когда вы запускаете 24/7 фоновые сервисы python через systemd, вы работаете напрямую с ядром Linux. Там просто нечему ломаться. Если сервер перезагрузится — система сама поднимет все службы в правильном порядке. Если скрипт начнет течь по памяти — лимиты systemd аккуратно перезапустят его, не задев соседние процессы.

Мы управляем парком из более чем 120 активных агентов для наших клиентов на нескольких VPS. За последний год у нас не было ни одного падения инфраструктуры. Бывали ошибки в логике, менялись API сторонних сервисов, но сама система доставки кода и его выполнения работала как швейцарские часы.

Разумный минимализм

Прежде чем тащить в свой проект очередной модный инструмент, спросите себя: «А смогу ли я починить это в три часа ночи с телефона?».

Если ваш стек состоит из Docker, Redis, Celery и Flower, то для починки вам придется зайти по SSH, проверить статус докера, посмотреть логи контейнера, проверить очереди в Redis... Если ваш стек — это Python и systemd, вы пишете одну команду: `systemctl status my-bot`. И сразу видите, где и почему упала конкретная строчка кода. Вы тратите на починку две минуты вместо двух часов.

Упрощайте. Пишите чистый код. Используйте силу операционной системы, в которую уже вложены десятилетия инженерного труда.

Если вам нужно автоматизировать бизнес-процессы, собирать данные, следить за сайтами или отправлять уведомления, но у вас нет времени возиться с настройкой серверов, логов и демонов — мы можем забрать эту головную боль себе. Мы в GuardLabs создаем, настраиваем и берем на полную поддержку стабильный, легкий и отказоустойчивый флот автономных Python-агентов на VPS (systemd + cron), работающий 24/7, чтобы вы могли сфокусироваться на бизнесе, а не на чтении серверных логов.