+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

RSS

Контейнеры Docker не запускаются на хосте Proxmox 9 / Debian 13 (раньше всё работало на Proxmox 8), Proxmox Виртуальная Среда

Peterkal

Guest

09.08.2025 18:17:00

Всем привет! Долгое время я запускал Docker прямо на хосте Proxmox 8 с Debian 12. В моей системе сосуществовали виртуальные машины и контейнеры Docker — всё работало идеально. Даже проброс GPU в контейнеры (Intel iGPU или NVIDIA) было просто настроить через Docker Compose, и он стабильно работал. После обновления до Proxmox 9 / Debian 13 мои ВМ по-прежнему работают нормально, а вот контейнеры Docker на хосте перестали запускаться. Появляются разные ошибки, связанные с правами на UNIX-сокеты, отказами AppArmor и сбоями IPC. Даже простые контейнеры, вроде Alpine или MariaDB, не стартуют. На одном обновленном хосте с NVIDIA GPU мне пришлось полностью отключить AppArmor, чтобы контейнеры снова заработали — и тогда всё пошло как надо, включая проброс GPU. Но отключать AppArmor — это рискованный костыль. Я не пытаюсь делать упор на проброс GPU — это просто приятный бонус. Главное — контейнеры Docker вообще не запускаются на хосте с Proxmox 9 / Debian 13 даже без всякой настройки GPU. Вопросы: Поддерживается ли официально запуск Docker на хосте в Proxmox 9? Существует ли профиль или настройка AppArmor, которая позволяет нормально запускать контейнеры Docker на Proxmox 9? Какой рекомендуемый способ запускать Docker-контейнеры прямо на хосте, не отключая AppArmor и не перенося всё в ВМ? Ищу официальное и безопасное решение, без обходных путей, которые снижают безопасность системы. Заранее спасибо!

zolakt Guest	#2 0 29.09.2025 15:22:00 Спасибо за это! Наверняка будет много критики, но если у кого-то нет более хорошего предложения, я пока так и сделаю. Из-за AppArmor я на виртуальные машины переходить не собираюсь.

joshx

Guest

26.10.2025 20:05:00

Есть очень веские причины запускать Docker прямо на хосте (да, это огромный костыль, который противоречит духу Proxmox и так далее), но в некоторых ситуациях это нормально. Например, как уже говорилось — passthrough не всегда возможен с виртуальной машиной. Например, видеокарту я не хочу отдавать ВМ, а диск, который использую для Docker (через `data-root` в `daemon.json`), хочу использовать совместно. ¯\_(ツ)_/¯

LnxBil

Guest

27.10.2025 10:56:00

Я не хочу спорить по поводу документации и полностью поддерживаю это (как уже неоднократно говорил в других обсуждениях). Для тех, кто всё равно будет этим заниматься: что насчёт золотой середины — запускать это в LX© контейнерах? Так вы получите лучшую изоляцию и при этом при желании сможете обращаться к драйверам и устройствам хоста. Я перешёл на такой вариант, и всё работает отлично.

joshx

Guest

27.10.2025 11:45:00

Потому что это не работает каждый раз, когда нужно обновиться (как видно из других обсуждений), и вообще без доработок оно не работает. Я, например, так и не смог запустить драйвер overlay2 и так далее. И правда ли это «официально одобренный» способ? Полностью согласен, что это не поддерживается, это «хакинг» или как там его, но всё равно ощущается как большой пощёчина. Согласен и с тем, что если нет веской причины, просто запускай это в виртуальной машине.

zolakt

Guest

27.10.2025 12:12:00

Меньшая нагрузка — вполне разумная причина для многих. Может быть, это однажды обернется против меня, но кроме этого изменения с apparmor у меня не было вообще никаких проблем с docker ни на хосте, ни на LXC. По крайней мере для домашних серверов, которые не выставлены в интернет или работают за VPN, я просто не вижу смысла в дополнительной нагрузке от виртуальной машины, если она не нужна.

Johannes S

Guest

27.10.2025 16:19:00

Что ж, кроме того, изменение с AppArmor — это реально проблема. По сути, вы просто отключили один из уровней безопасности, чтобы сделать по-своему. Можете назвать меня параноиком, но, на мой взгляд, «отключать безопасность» никогда не должно быть решением. И если кому-то приходится делать это «чтобы сэкономить ресурсы», стоит хорошенько подумать, нужен ли им вообще гипервизор. Если рабочая нагрузка в основном состоит из контейнеров Docker, можно просто поставить любимый дистрибутив Linux с Docker и/или Podman и какой-нибудь управляющий интерфейс (например, Portainer или Dockge). Вместе с vm-manager можно даже настроить виртуальную машину, если она вдруг понадобится (например, для HomeAssistant или Windows).

Если хотите остаться с ProxmoxVE, то «накладные расходы» на использование виртуальных машин для контейнеров Docker/Podman, на мой взгляд, сильно преувеличены: можно сделать Docker-виртуалку на Debian или Alpine с минимальными спецификациями, например 2 ГБ ОЗУ или даже меньше (помню, кто-то в этом форуме говорил, что у него есть Docker-виртуалки с 1 ГБ или даже 512 МБ ОЗУ). Если сложить все ваши контейнеры в одну виртуалку, вы практически не потеряете в производительности по сравнению с установкой на «голое железо» или LXC.

reinob

Guest

27.10.2025 17:05:00

Я запускаю небольшое веб-приложение в докере на Debian 13 в виртуальной машине с выделенными 512 МБ ОЗУ (и без свопа). Времена, когда виртуалки работали медленнее «железа», давно прошли, но некоторые особенности остаются навсегда.

zolakt

Guest

27.10.2025 19:57:00

Если бы это был один виртуальный сервер для запуска всех контейнеров Docker, проблем бы не было, но при нескольких — нагрузка растёт. Например, у меня много VLAN’ов, и на большинстве из них нужны контейнеры Docker. Запустить это всё на одном хосте Docker не получится (по крайней мере, без жёстких прописываний IP, которые DHCP не видит, а я этого делать не хочу). К тому же большинству этих хостов нужен GPU. С виртуальными машинами пришлось бы делить или выделять его строго, а LXC могут его разделять, и каждый сможет использовать всё по максимуму, когда нужно. Для моего случая меньшее потребление ресурсов и удобство важнее apparmor, учитывая, что это домашняя лаборатория, полностью за VPN, без публичного доступа. Понимаю, что это не по канонам, но я не считаю это кощунством и не думаю отказываться от Proxmox только из-за того, что обходил apparmor.

BobhWasatch Guest	#10 0 27.10.2025 19:59:00 На одной виртуальной машине можно настроить несколько VLAN. Все они могут использовать DHCP.

BobhWasatch Guest	#11 0 27.10.2025 20:00:00 Одно, что я не понимаю в хомелаберах — это когда они используют кучу VLAN-ов и при этом следят, чтобы между ними была полная связность.

zolakt

Guest

#12

27.10.2025 20:05:00

Не мог бы ты объяснить, как это сделать? Я не эксперт, но у меня не получилось запустить это на bare metal Docker. Получилось только с macvlans, и то пришлось прописывать IP-адреса вручную. Когда я спрашивал совета, никто не предложил решения и отправил меня к Proxmox. Сейчас переключаться не собираюсь — меня вполне устраивает моя настройка Proxmox, но мне бы действительно хотелось понять, как это сделать на bare metal. Кстати, у меня нет полной связности между VLANами. А это ведь одна из основных причин их использования. Очень строгий файрвол для меж-VLAN-трафика и обрубание интернета на большинстве из них.

Johannes S

Guest

#13

27.10.2025 20:16:00

Не обязательно: https://pve.proxmox.com/wiki/Kernel_Samepage_Merging_(KSM) Сейчас KSM — это тоже своего рода компромисс (есть ситуации, когда его можно использовать в злонамеренных целях, например, для атак rowhammer), но, по моему мнению, всё равно лучше, чем запускать Docker с отключённым AppArmor на хосте.

Marx

Guest

#14

05.12.2025 11:07:00

Привет! Я использую не только Docker, но и полноценный k3s на узлах Proxmox. Kubernetes — моя основная среда, а Proxmox задействую лишь в крайнем случае, когда что-то не может работать в контейнере и действительно нужна виртуальная машина (читай: Windows VM). В этом случае Proxmox становится гостевой системой. Такое решение в основном связано с расходом ресурсов: Kubernetes управляет ими эффективно, а виртуальной машине нужно выделять ресурсы статично. Есть и другие аргументы, но не в этом суть. Суть в том, что обновление до версии 9 нарушило работу моего Kubernetes из-за безопасности AppArmor. Я использовал эту конфигурацию 5 лет, так что «никто не ожидал испанской инквизиции». Вопрос: как теперь быть с этой проблемой? Могу удалить Proxmox, но иногда (редко) он мне всё же нужен. Могу отключить AppArmor. Есть ли какие-то другие решения?

Johannes S

Guest

#15

05.12.2025 12:21:00

Ты запускаешь k3s напрямую на узлах Proxmox или внутри виртуальной машины? И запускаешь PVE в виде виртуальной машины на kubevirt или на «голом» железе? Если твой главный движок — это k3s, я бы посоветовал устанавливать его на «голое» железо, а не поверх PVE или внутри виртуалки, потому что ни K3S, ни PVE не предназначены для одновременной работы на одном и том же «голом» сервере.

Marx Guest	#16 0 05.12.2025 19:48:00 У меня оба установлены одновременно на "чистую" систему, и пока что они работали без проблем. Я отключил AppArmor в grub, и всё снова заработало. Безобразие, я знаю.

pulipulichen Guest	#17 0 09.03.2026 10:35:00 Я столкнулся с похожей проблемой при тестировании Docker внутри LXC контейнера. Моя среда — непривилегированный LXC с Ubuntu 25.04 на хосте Proxmox 8.4.9 (Kernel 6.8.12-13-pve). Я уже применил рекомендованный обход через systemctl edit docker, добавив Environment=container="disable apparmor". Однако, когда пытаюсь выполнить docker run hello-world, контейнер всё равно не запускается с такой ошибкой: Похоже, что runc всё ещё упирается в ограничение при попытке доступа к net.ipv4.ip_unprivileged_port_start из-за ужесточённых профилей безопасности в новой среде, даже с установленной переменной окружения. Есть ли более точечная корректировка профиля AppArmor для такого случая или, может быть, какая-то другая настройка, необходимая для Ubuntu 25.04 в гостевой системе? Я проверил, что «Nesting» включён в настройках LXC, но проблема сохраняется. Буду очень признателен за советы, как правильно с этим справиться.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры