Когда Docker избыточен на VPS: как выбрать простой инструмент без лишних слоёв

Когда Docker — лишнее: как не усложнять инфраструктуру на VPS

Docker давно стал стандартом для упаковки приложений, но на небольшом сервере его накладные расходы часто перевешивают удобство. Даже в простоях демон dockerd, containerd и служебные процессы (containerd-shim-runc-v2) потребляют память и CPU. На VPS с 1–2 ГБ RAM это может вылиться в свопинг или срабатывание OOM killer. OverlayFS усугубляет ситуацию: при каждом изменении файла в контейнере система копирует его из нижнего слоя в верхний записываемый, и со временем это разрастается, занимая диск. Без регулярной очистки образы, остановленные контейнеры и неиспользуемые тома быстро забивают систему.

Docker также означает root. Демон dockerd требует привилегий суперпользователя, а добавление пользователя в группу docker даёт ему полный контроль над узлом. Docker переписывает iptables, добавляя цепочки DOCKER-*, что ломает привычные настройки ufw или nftables. Исправление требует ручной правки цепочки DOCKER-USER. Контейнеры по своей природе эфемерны: данные внутри них теряются при пересоздании, а для постоянного хранения нужны volumes.

Пять сценариев, где Docker избыточен

В этих случаях контейнеризация не упрощает жизнь, а добавляет новые слои сложности:

• Одиночный сервер с одним приложением и базой (например, Node.js, PostgreSQL и nginx).
• Игровые серверы (Minecraft, Rust, CS), где Docker добавляет слой NAT и усложняет проброс портов.
• VPS с 1–2 ГБ RAM, где накладные расходы Docker становятся заметными даже в простое.
• Сервисы с низкой задержкой (VoIP, видеосвязь, IoT-брокеры).
• Администрирование в свободное время (личный блог или домашнее хранилище), где важнее простота.

Podman: безопасность «из коробки» без демон-костылей

Podman решает часть проблем Docker за счёт бездемонной архитектуры. Он работает через libpod и по умолчанию запускается rootless, не требуя ручной настройки RootlessKit. Привилегии по умолчанию ограничены 11 системными возможностями против 14 у Docker, что снижает поверхность атаки. Интеграция с SELinux и прозрачный аудит (логи привязаны к пользователю, а не к root) делают его безопасным «из коробки».

Но у Podman есть ограничения. Экосистема беднее: меньше готовых образов, слабее поддержка в CI/CD-пайплайнах. Совместимость с Docker CLI через алиас podman вместо docker снижает порог входа, но не решает проблему зрелости экосистемы. Rootless-режим в Docker, напротив, требует ручной настройки и не работает с Docker Swarm — ещё один аргумент в пользу Podman для безопасности.

Incus/LXD: системные контейнеры для изоляции окружений

Если нужен не переносимый артефакт, а полноценное изолированное окружение, Incus/LXD предлагают другой подход. Это system containers с полноценными Linux-окружениями: systemd, пакетный менеджер, пользователи, cron. Такой вариант удобен для self-hosted-стека, где нужно управлять несколькими изолированными инстансами — например, отдельный контейнер под PostgreSQL, reverse proxy, Git-сервер.

Incus — развитие LXD с акцентом на предсказуемое администрирование: инстансы, профили, storage-пулы, bridge-сети. Удобство снимков и клонирования позволяет быстро разворачивать staging-окружения или тестировать обновления. В отличие от Docker, Incus поддерживает запуск виртуальных машин внутри контейнеров.

Systemd + venv + nginx: минимализм без лишних слоёв

Когда на сервере одно приложение, база и веб-сервер, контейнеризация избыточна. Достаточно системных пакетов из репозитория, изоляции через venv для Python и управления жизненным циклом через systemd. Такой подход не требует дополнительных инструментов, не добавляет накладных расходов и проще в отладке.

Операционные трения: где начинаются реальные проблемы

Даже лучшие инструменты требуют ручной доводки. В учебном стенде на LXD Ubuntu-контейнеры по умолчанию разрешают SSH только по ключу. Чтобы включить парольный доступ, приходится править конфиг через lxc exec:

lxc exec test -- bash -c "sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null; systemctl restart ssh"

Другая проблема — сетевые конфликты. В стенде с LXD apt зависал из-за отсутствия IPv6-маршрута, а Docker переписывал iptables, блокируя транзитный трафик моста lxdbr0. Решение: отключение IPv6 для моста и добавление правил iptables.

Что меняет выбор инструмента

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

Практическое правило:

• Если на сервере одно приложение + база + nginx и ресурсов мало — используйте systemd + venv + nginx.
• Если нужен переносимый артефакт для деплоя — выбирайте Docker.
• Если приоритет — безопасность и rootless-режим «из коробки» — Podman.
• Если нужны изолированные Linux-окружения (например, для self-hosted-стека) — Incus/LXD.