Docker или виртуальная машина для домашнего сервера: что выбрать в 2025 году

Введение: зачем выбирать между Docker и VM

Домашний сервер почти всегда начинается с одного вопроса: запускать сервисы в контейнерах или в виртуальных машинах? Оба подхода решают одну задачу — изолировать приложения друг от друга, — но делают это на разном уровне. Контейнеры делят ядро хоста, а виртуальные машины эмулируют отдельное железо. Выбор влияет на потребление RAM, скорость обновлений, проброс GPU и USB, а также на то, насколько просто восстановить сервис после сбоя.

Как устроены контейнеры и виртуальные машины

Контейнер — это процесс на хосте, изолированный с помощью пространств имён (namespaces) и ограничений ресурсов (cgroups). Он использует ядро хост-системы и не содержит собственного ядра. Виртуальная машина запускает полноценную гостевую ОС со своим ядром через гипервизор: KVM, Xen, VMware, Hyper-V. Гипервизор распределяет CPU, RAM, диски и сеть между виртуальными машинами.

Изоляция и безопасность

Контейнеры изолируют процессы, но разделяют ядро. Ошибка в ядре или неверные capabilities могут затронуть хост. На практике Docker с rootless-режимом, seccomp, AppArmor и непривилегированными пользователями даёт достаточную защиту для домашних сервисов. Виртуальные машины изолируют сильнее: компрометация гостя не даёт прямого доступа к хосту без уязвимости гипервизора. Для публично доступных сервисов VM предпочтительнее.

Накладные расходы и производительность

Контейнер потребляет почти столько же ресурсов, сколько сам процесс. Виртуальная машина добавляет слой гипервизора и гостевую ОС: обычно 0.5–2 ГБ RAM на холостом ходу и 5–15% CPU на виртуализацию ввода-вывода. На слабом железе (N100, старый i3) это заметно. На серверных CPU разница меньше, но RAM всё равно тратится на каждую гостевую ОС.

• Контейнеры: запуск за секунды, минимум RAM, быстрое масштабирование.
• VM: запуск за десятки секунд, фиксированное выделение RAM, выше задержки дискового ввода-вывода.
• Для 10–20 лёгких сервисов Docker экономит 4–8 ГБ RAM по сравнению с VM.
• Для одного тяжёлого сервиса с чужеродной ОС (Windows, BSD) VM незаменима.

Проброс оборудования (hardware passthrough)

GPU, USB-координаторы, HBA и сетевые карты можно передавать и в контейнеры, и в VM, но механика разная. В Docker пробрасывают device-файлы (/dev/dri, /dev/ttyUSB0) и группы, в VM — через PCI passthrough или USB-перенаправление гипервизора. Для GPU-транскодинга в Docker достаточно смонтировать /dev/dri и установить драйверы на хосте. В VM нужен проброс всего GPU или vGPU.

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    devices:
      - /dev/dri:/dev/dri
    group_add:
      - "989"  # render group
    volumes:
      - ./config:/config
      - ./media:/media

Резервное копирование и восстановление

У контейнеров бэкап сводится к сохранению томов и конфигов. У VM — к снимкам диска и экспорту целиком. Снимки VM удобны для отката, но занимают много места. Для Docker используйте bind-mount вместо анонимных томов: так проще копировать данные. Регулярно проверяйте восстановление, иначе бэкап бесполезен.

1. Остановите контейнер или БД перед копированием, либо используйте дампы (pg_dump, mysqldump).
2. Скопируйте каталоги конфигов и данных на отдельный носитель.
3. Для VM делайте снимок или экспорт OVA/QCow2.
4. Раз в квартал восстанавливайте сервис на тестовом хосте.

Jellyfin: транскодирование и GPU

Jellyfin отлично работает в Docker. Главное — пробросить GPU для аппаратного транскодинга. На Intel это /dev/dri, на NVIDIA — nvidia-container-toolkit. В VM проброс GPU сложнее и часто невозможен на потребительском железе. Поэтому для Jellyfin чаще выбирают Docker.

Home Assistant: USB-координаторы и супервизор

Home Assistant OS официально поставляется как образ для VM или одноплатника. В Docker возможен вариант Container, но без супервизора и дополнений. Если нужны Zigbee/Z-Wave USB-стики, в Docker пробрасывают /dev/ttyUSB0 или /dev/ttyACM0. В VM USB перенаправляют через гипервизор. Для новичков проще HAOS в VM.

Nextcloud: данные, БД и обновления

Nextcloud в Docker удобен, но требует внимания к БД и хранилищу. Используйте отдельные контейнеры для PostgreSQL и Redis, а данные монтируйте на хост. Обновления через смену тега образа; перед этим делайте бэкап БД и каталога data. В VM обновление целой системы проще откатить снимком.

Базы данных: PostgreSQL и MySQL в контейнере или VM

БД в контейнере работают быстро, если данные лежат на хосте через bind-mount. Но при обновлении образа нужно следить за совместимостью версий. В VM проще выделить ресурсы и делать снимки. Для домашних нагрузок оба варианта допустимы; для критичных данных выбирайте VM или отдельный хост.

Сеть и доступ извне: порты, reverse proxy, VPN

В Docker порты публикуются через -p, в VM — через мосты и NAT. Для доступа извне используйте reverse proxy (Nginx, Caddy, Traefik) и VPN (WireGuard, Tailscale). Не открывайте порты БД и админок в интернет. В Docker удобно ставить Traefik с автоматическими сертификатами.

Хранение данных и тома

В Docker различайте тома и bind-mount. Тома управляются Docker, bind-mount — вами. Для домашнего сервера предпочтительнее bind-mount: данные видны, легко бэкапить. В VM диски — это файлы образов; их можно расширять и снимать. Не храните важные данные только внутри контейнера.

Обновления и откат версий

В Docker обновление — смена тега образа и перезапуск. Откат — возврат к предыдущему тегу. В VM обновление — это обновление гостевой ОС; откат — восстановление снимка. Для стабильности фиксируйте версии образов, а не используйте latest.

Мониторинг и логирование

В Docker логи собираются через docker logs или драйверы (json-file, journald). В VM — внутри гостевой ОС. Для централизованного мониторинга подойдут Prometheus, Grafana, Uptime Kuma. Следите за свободным местом: логи и образы быстро растут.

Типичные ошибки новичков

Гибридный подход: VM с Docker внутри

Часто оптимален гибрид: Proxmox или другой гипервизор, внутри — VM для HAOS и отдельная VM с Docker для остальных сервисов. Это даёт изоляцию и удобство. Такой подход популярен на домашних серверах с 16–32 ГБ RAM.

Критерии выбора под ваш сценарий

• Нужна чужая ОС (Windows, BSD) — VM.
• Нужен GPU-транскодинг — Docker.
• Нужен HAOS с супервизором — VM.
• Много лёгких сервисов — Docker.
• Критичные данные и снимки — VM.
• Слабый CPU и мало RAM — Docker.

Итоговые рекомендации

Для большинства домашних серверов оптимальна гибридная схема: гипервизор + VM с Docker. Если ресурсов мало, начните с Docker и добавляйте VM по необходимости. Главное — регулярные бэкапы, фиксированные версии и понимание, где хранятся данные.