Полный обзор контейнеров в Proxmox VE 9.1: Docker VMs, LXC, и новые OCI

Что изменилось в Proxmox VE 9.1

Для начала разберёмся, что появилось нового в Proxmox VE 9.1, на случай, если это обновление прошло мимо внимания или не было прочитано вводное описание. Полный обзор доступен здесь: Proxmox VE 9.1 Launches with OCI Image Support, vTPM Snapshots, and Big SDN Upgrades.

Ниже показан экран локального хранилища шаблонов, где в Proxmox VE 9.1 появился новый пункт меню Pull from OCI Registry.

Ниже – краткий список ключевых изменений:

• Появилась нативная поддержка OCI‑контейнеров – теперь можно выполнять pull, обновлять и запускать OCI‑образы непосредственно на хосте Proxmox без отдельной Docker‑VM.
• Появилась поддержка шаблонов контейнеров, собираемых из OCI‑образов.
• Реализована поддержка OCI‑реестров, включая Docker Hub, GHCR, Quay и кастомные реестры.
• Можно использовать снимки и резервные копии для OCI‑контейнеров с применением системы хранения Proxmox, включая ZFS.
• Добавлены улучшения SDN, применимые как к контейнерам, так и к виртуальным машинам.
• Реализована интеграция с существующей системой прав и хранилищ Proxmox для унифицированного управления контейнерами.

Это серьёзный шаг вперёд для энтузиастов домашней лаборатории, которые хотят уменьшить «зоопарк» виртуальных машин, используемых исключительно под контейнеры. Благодаря возможности нативного запуска OCI‑контейнеров в Proxmox можно, например, забрать образ приложения из Docker Hub, и Proxmox автоматически развернёт его внутри LXC‑контейнера «под капотом», но при этом будет использовать именно OCI‑контейнер. То есть, Docker Engine в Proxmox 9.1 не добавлен – вместо этого используется технология LXC для запуска OCI‑образа.

У такого подхода есть заметные преимущества: нет необходимости поднимать отдельный хост Docker в виде VM на Proxmox. Кроме того, запуск Docker внутри LXC официально не поддерживается. И даже если сами LXC‑контейнеры довольно «лёгкие», при ручной установке приложений внутри LXC всё равно приходится выполнять массу шагов установки для каждого приложения.

К недостаткам OCI‑контейнеров в Proxmox 9.1 можно отнести то, что функция совершенно новая и находится на стадии Technology Preview, а не GA. Также пока нет встроенного и очевидного механизма обновления таких OCI‑контейнеров.

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

Docker VM

Запуск Docker или Podman внутри виртуальной машины по‑прежнему остаётся самым гибким способом работы с контейнерами в Proxmox. Это простой и понятный вариант для развёртывания Docker‑контейнеров. Рабочий процесс выглядит так: создаётся виртуальная машина, на неё ставится ОС (например, Ubuntu Server или Debian), затем устанавливается Docker, после чего запускаются контейнеры приложений. Можно использовать «голый» Docker Compose из командной строки либо инструменты вроде Portainer или Komodo, а также запускать контейнеры с помощью Kubernetes‑дистрибутивов, таких как k3s.

Плюсы использования Docker VM

• Полная совместимость с любыми решениями, разработанными под Docker или Kubernetes.
• Это наиболее распространённый способ запуска Docker в продакшене.
• Поддержка продвинутых сетевых возможностей: macvlan, IPvlan, overlay‑сети, Swarm, CNI‑плагины k3s.
• Лёгкая интеграция с такими инструментами, как Portainer, cAdvisor, экспортеры Prometheus, Traefik и Watchtower.
• Можно делать снимки и восстанавливать всю виртуальную машину вместе со всеми контейнерами.
• Высокая портируемость: VM можно переносить между хостами домашней лаборатории, облаками или тестовыми кластерами.
• Чёткое разделение ОС хоста Proxmox и среды выполнения контейнеров.

Минусы Docker VM

• Оверхед ресурсов из‑за самой виртуальной машины.
• Менее эффективный вариант по сравнению с LXC или нативными OCI‑контейнерами Proxmox.
• Дополнительные операции по обслуживанию – требуется патчить ОС внутри VM.
• Больше уровней между «железом» и контейнерами.

Когда Docker VM – правильный выбор

Если планируется запуск большого количества контейнеров, используется Docker Compose, есть зависимость от Portainer или Traefik, либо требуется разворачивать Kubernetes, Docker‑VM остаётся лучшим и наиболее предсказуемым вариантом. При планах селф‑хостинга 10–30 контейнеров или целых стеков (например, Gitea с раннерами, Nextcloud, Plex, FreshRSS, Nginx Proxy Manager) именно Docker‑VM остаётся оптимальным решением.

LXC-контейнеры

Одной из лучших возможностей Proxmox традиционно считается поддержка нативных LXC‑контейнеров. В таких гипервизорах, как VMware и других, зачастую нет встроенного простого механизма для работы с контейнерами. Да, в VMware есть Tanzu для Kubernetes, но его запуск в vSphere связан с высокой сложностью, множеством требований, компонентов и подводящих систем.

В Proxmox LXC‑контейнеры создаются примерно так же просто, как новая виртуальная машина. Они очень быстрые, так как используют ядро хоста Proxmox и имеют минимальный оверхед, что особенно ценно для селф‑хостинга. Можно делать снимки, резервные копии и другие привычные операции.

Однако LXC – это больше «ОС‑ориентированные» контейнеры. Они ближе к полноценным виртуальным машинам, чем к прикладным контейнерам. Здесь уместен Docker. В теории может показаться, что LXC‑контейнеры отлично подошли бы на роль хостов Docker, но такой сценарий официально не поддерживается. Поэтому исторически приходилось выбирать: либо LXC‑контейнеры, либо Docker‑контейнеры.

Плюсы использования LXC

• Очень высокая скорость работы и минимальный оверхед.
• Как правило, им требуется меньше ресурсов, чем полному хосту Docker в виде VM.
• Глубокая интеграция с Proxmox: сеть, хранилище, права доступа, резервное копирование.
• Поддержка непривилегированных контейнеров повышает безопасность.
• Отлично подходят для статлесс‑сервисов или лёгких приложений.
• Доступно клонирование, создание снимков и репликация.

Минусы LXC

• Могут попадаться приложения, которые нельзя официально запускать внутри LXC из‑за системных ограничений или требований к привилегиям.
• Многие Docker‑контейнеры невозможно просто «перенести» в LXC, поскольку они завязаны на cgroups, определённые модули ядра или операции с повышенными правами.
• Если требуется systemd, иногда приходится дополнительно настраивать окружение, чтобы оно корректно работало внутри LXC.

Когда LXC – правильный выбор

LXC‑контейнеры уместны во многих сценариях. Например, можно разместить в них такие приложения, как Pi‑Hole или AdGuard Home. Также они хорошо подходят для простых веб‑серверов, лёгких инструментов мониторинга, баз данных или кастомных приложений – зачастую всё это отлично работает внутри LXC.

Исторически, если нужно было запустить контейнеризованные приложения, распространяемые в виде Docker‑образов формата OCI, приходилось либо вручную конвертировать их в формат LXC (что мало кто делал на практике), либо поднимать Debian или Ubuntu в виде VM и устанавливать Docker уже в самой виртуальной машине.

OCI-контейнеры

На этом этапе становится понятна роль новой поддержки OCI‑образов в Proxmox VE 9.1. Она заполняет пробел между полноценной Docker‑VM и запуском LXC‑контейнеров для приложений. Благодаря нативной поддержке OCI‑образов можно напрямую забирать OCI‑совместимые образы из тех же реестров, которые используются для Docker‑контейнеров.

Это важное новшество, поскольку потенциально может свести на нет необходимость держать полнофункциональные Docker‑хосты в виде виртуальных машин на Proxmox. Вместо этого достаточно выполнить pull OCI‑образа и запустить Docker‑совместимый образ внутри нового OCI‑совместимого LXC‑контейнера.

При выполнении pull OCI‑образов из Docker Hub, GHCR, Quay, Harbor или приватного реестра Proxmox может хранить их слои в собственной системе хранения. Затем такие OCI‑контейнеры воспринимаются как управляемые объекты, аналогично LXC‑контейнерам или VM.

«Под капотом» для развёртывания OCI‑образа используется LXC‑контейнер. Это может показаться немного нетривиальным, однако с точки зрения администрирования это удобно: можно назначать ресурсы LXC/OCI‑контейнеру точно так же, как любому другому объекту, включая VLAN.

Плюсы OCI-контейнеров в Proxmox

• Могут устранить необходимость в Docker‑хостах в виде VM.
• Меньший оверхед по сравнению с Docker‑VM.
• Совместимость со стандартными OCI‑образами из Docker Hub и других реестров.
• Нет необходимости устанавливать Docker или Podman.
• Интеграция с системами резервного копирования и снимков Proxmox.
• Снижают количество виртуальных машин, необходимых для инфраструктуры.
• Более безопасный вариант по сравнению с запуском Docker напрямую на хосте Proxmox (чего делать не рекомендуется).

Минусы OCI-контейнеров в Proxmox

• Функциональность абсолютно новая и пока находится в статусе Technology Preview.
• На данный момент нет официального механизма обновления OCI‑образов, развёрнутых таким способом.
• Не является полноценной заменой Docker: нельзя запускать все стеки Docker Compose.
• Нет поддержки продвинутых сетевых возможностей Docker, таких как macvlan или overlay‑сети, хотя можно настраивать сеть на уровне LXC.
• Нет прямой замены для оркестрации Kubernetes или Swarm.
• Ограниченный набор инструментов для разработчиков по сравнению с Docker.

Когда OCI в Proxmox может быть правильным выбором

Если требуется развернуть один контейнерный образ без поднятия полноценной виртуальной машины, OCI‑образы отлично подходят для этой задачи. Типичные сценарии:

• Один экземпляр Uptime Kuma.
• Dozzle.
• Лёгкая панель мониторинга или дашборд.
• Один микросервис.
• Небольшая база данных.
• Простые фоновые воркеры.

Если цель – снизить оверхед на VM и легко разворачивать лёгкие сервисы из OCI‑образов Docker Hub, поддержка OCI в Proxmox выглядит очень удачным компромиссом.

Сравнение Docker VM, LXC и OCI-контейнеров

Ниже приведена простая таблица сравнения трёх способов запуска контейнеризованных приложений в Proxmox в конце 2025 года:

С учётом всего сказанного о трёх вариантах запуска контейнеризованных приложений в Proxmox в конце 2025 года можно отметить: Docker‑VM по‑прежнему обеспечивает наибольшую гибкость и лучше всего подходит для сложных контейнерных стеков, используемых в реальных сценариях. LXC‑контейнеры по‑прежнему актуальны, обеспечивают отличную производительность и низкий оверхед, но непосредственно с OCI‑образами не совместимы (требуется конвертация). OCI‑контейнеры (новинка Proxmox 9.1) занимают удачную «среднюю позицию» для лёгких приложений, которые нужно разворачивать непосредственно на узле, и позволяют запускать их без предварительной установки Docker.

Какой вариант лучше в конце 2025 года?

В качестве упрощённого правила выбора между Docker‑VM, LXC и OCI‑контейнерами Proxmox можно ориентироваться на следующие рекомендации.

Используйте Docker VM, если:

• Запускается больше нескольких контейнеров.
• Есть зависимость от Docker Compose.
• Используются Portainer, Traefik, Authelia или другие многоконтейнерные приложения.
• Важно, чтобы хост Proxmox оставался максимально «чистым».
• Нужно иметь возможность мигрировать Docker‑VM на другой узел или в другой кластер.

Используйте LXC, если:

• Нужна высокая производительность и низкий оверхед.
• Используемые приложения корректно работают в LXC.
• Важна простота создания снимков и клонирования.
• Есть склонность запускать небольшие отдельные сервисы без поднятия отдельной VM.

Используйте OCI-контейнеры Proxmox, если:

• Нужен лёгкий способ запустить один‑два контейнерных образа.
• Планируется использовать те же образы, которые размещены на Docker Hub.
• Хочется избежать запуска полноценной Docker‑VM.
• Требуется, чтобы OCI‑контейнеры (основанные на Docker‑образах) были нативными объектами Proxmox.
• Разворачиваемые приложения имеют простые требования к рантайму.

Сводная таблица вариантов и сценариев применения:

Итоги

С выходом Proxmox VE 9.1 домашние лаборатории получили больше вариантов, чем когда‑либо раньше. Proxmox всё больше становится предпочтительным гипервизором для работы с контейнерами именно благодаря множеству вариантов организации контейнерной инфраструктуры. По‑прежнему можно использовать полноценные виртуальные машины как Docker‑хосты там, где это наиболее уместно (и, скорее всего, ещё долго будет так в продакшене). Остаются LXC‑контейнеры как быстрый и удобный «VM‑подобный» вариант для развёртывания приложений. И теперь добавилась новая поддержка OCI‑контейнеров в Proxmox 9.1, которая даёт третью, очень удачную опцию и выглядит как потенциальный «game changer». Интересно, пробовались ли уже эти возможности и как они повлияют на домашние лаборатории и продакшен‑среды?