# LXC vs VM для докера и не только **URL:** \ **Category:** Proxmox\ **Created:** [06.Июль.2025 23:31:48 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488 "2025-07-06T23:31:48Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [06.Июль.2025 23:31:48 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/1 "2025-07-06T23:31:48Z")
Навеено [статьей](https://pve.proxmox.com/wiki/Linux_Container) в официальной документации ### Что такое LXC контейнеры (CT в терминологии PVE) Это контейнеризация в Linux, которая работает аналогично docker, но при этом, если внутри docker контейнера по-умолчанию крутится 1 процесс, то LXC держит полноценный init (да?) c SSH и прочими ништяками, но при этом ядро ОС одно как для контейнера, так и для хоста ### Что такое KVM (VM в терминологии PVE) Это паравиртуализированная виртуальная машина, которая с точки зрения гостя является полностью независимой от хоста, может быть как linux, так и любой другой ОС и даже иметь другую архитектуру (если мы говори про qemu, естественно, в этом случае уже ни о какой паравиртуализации речи не идет) ### Плюсы CT по сравнению с VM 1. Меньше оверхед, alpine linux прям очень легкий, сотни контейнеров тянуть проще, нежели сотни виртуалок, при этом ядро одно и переключений контекста меньше 2. Быстрее и проще установка, по сути, надо распаковать архив и настроить параметры (в VM частично реализуется через cloud init) 3. Консоль из коробки 4. Лучше распределение ресурсов, в чистом LXC и LXD вообще может не быть ограничений на оперативку и процессор для контейнера и он может использовать все доступные ресурсы, резервирования нет, с одной стороны это хорошо, т.к. можно больше уместить в одном сервере, с другой стороны можно словить OOM когда не ожидаешь ### Плюсы VM 1. Выбор гостевых систем практически неограничен 2. Практически идеальные изоляция и функционал, т.к. нет общего ядра, оперативки, файлов. 3. Совместимость выше, NFS шара работает, какие-то приколюхи работают, например, у меня пока не получилось запустить podman в alpine linux внутри LXC контейнера в PVE, SSSD работает, в LXC freeIpa пользователи у меня не работали т.к ID пользователей слишком большие т.к. они транслируются в ID хоста 4. Безопасность выше, особенно с учетом 3 пункта, когда не все работает в непривилегированном контейнера, а перевод его в привилегированный режим рушит изоляцию и безопасность 5. Работают живые миграции между нодами когда без перезагрузки виртуалка переtзжает на другую ноду, у меня максимум 1 пинг терялся, в LXC миграция только с перезапуском 6. Работает ZFS over ISCSI - это прям крутая штука, когда NAS или SAN выдает блочное устройство, я проверил дома и отзывчивость по сравнению с ZFS over NFS на порядок выше (вот [проект](https://github.com/boomshankerx/proxmox-truenas)) ### Что по хостингам 1. Сейчас цены выросли, а лет 10 назад многие любили продавать opvenVZ, это аналог LXC, при этом они были дешевле KVM за счет того, что можно было за счет массового обслуживания с оверсейлить ресурсы и заработать больше, например, через на 10 ГБ оперативки делится на 20 “VDSок” по 1-2-4 ГБ оперативки, но без гарантии выделеиня этих ресурсов. Но при этом, OpenVPN не поставить, какие-то сервисы, ктрубующие модули ядра не поставить и т.д. ну и постоянные ООМ 2. Сейчас в том числе по причинам безопасности предлагают KVM, но все равно оверсейлят, еще я подозреваю, что для KVM проще подкинуть диск ### Как снизить оверхед как в LXC так и в KVM режиме 1. Я нашел для себя Alpine linux, (есть и другие варианты, можете накидать в комментах) раньше использовал в качестве базового образа для docker, а теперь перевел почти все LXC контейнера на него и попробовал в VM. Но там есть момент с libc, это может быть критичным. 2. Ну понятно, что выкидывать ненужный функционал, с влучае с Alpine выкидывать нечего, надо добавлять только нужный, в случае Ubuntu/debian я находил скрипт, который удаляет лишне и оставляет только docker 3. Смотреть в сторону легковесных альтернатив, например busybox заменяет кучу всего, dropbear вместо openssh и т.д. даже crond можно заменить на реализацию в busybox 4. Для VM можно влкючать Balloning device, это когда часть оперативки гостевой ОС раздается другим системам, можно выделить, например, от 2 до 4 ГБ оперативки и при старте будет выделяться 4, а потом при помощи этого самого воздушного шара 2 ГБ резервироваться и этот резерв переиспользоваться, при этом, если гостю надо будет больше 2ГБ и эти ресурсы будут свободные на хосте, то это резервирование уменьшается и ПО внутри гостя может использовать эту оперативку 5. Для VM использовать virtio и guest-agent, virtio для windows гостей дает прям большой буст производительности ### Что я выбирают для себя 1. У мня дома более 50 CT и VM на мини ПК, я использую подход Application Containers, но Proxmox это не рекомендуют, они за System Containers и VM 2. Если есть неограниченные ресурсы и время на разворачивание, то однозначно VM, но даже если не заморачиваться с автоустановкой и провижинингом, то LXC развернуть пару минут надо, а VM чуть подольше 3. Если не создавать под каждое приложение LXC контейнер, а по виртуалке на ноде и там развернуть K8S или его аналоги, то тоже лучше VM 4. Очень не люблю расширять хост PVE, видел статьи где docker ставится на PVE и потом все крутиться там, но это дичь полная, удивляюсь, что PVE это позволяет, вот Truenas отключили apt и рады ### Выводы Пользуйте в качестве выводов предыдущий параграф, а если не согласны или хочется дополнить, то прошу высказать свои мысли в комментариях. ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [23.Сентябрь.2025 21:47:36 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/2 "2025-09-23T21:47:36Z")
Еще раз попробую объяснить **Если у вас дикий энтерпрайз, а именно** 1. Выделяются деньги на железо и софт 2. Выделяются деньги на штат специалистов 3. Имеются повышенные требования к безопасности 4. Стоимость минуты простоя очень высокая 5. Требуется максимальная совместимость **То однозначно следует выбирать VM т.к. она позволяет** 1. Максимально качественно разделить хост и гостевое окружение на уровне ядра, процессов, памяти (в том числе) 2. Обеспечить паравиртуализацию ресурсов на уровне гипервизора 3. Иметь возможность мигрировать виртуалки с машины на машину без даунтайма за счет копирования содержимого оперативной памяти 4. Устанавливать необходимые модули ядра, монтировать SMB и NFS шары, менять ядро, тюнить его, например, менять планировщик 5. Резервировать ресурсы (CPU и RAM) под виртуалку (на самом деле, переиспользование незанятой оперативки это целый механизм драйверов гостевой системы) 6. Устанавливать различные версии ядра и вообще операционки, например, совмещать windows и linux 7. Настраивать сетевые интерфейсы внутри виртуальной машины 8. Передавать специфичные устройства типа TPU чипов, UEFI, **Если у вас самохостинг и** 1. Какой-нить мини ПК, списанный сервак или мащинист на Z99 2. На приказ ФСТЭК №21, оценка безопасности КИИ и ГОСТ Р ИСО/МЭК 27001-2021 у вас только одна [реакция](https://cs14.pikabu.ru/video/2022/03/24/1648123800255426522_640x360.webm) 3. Вы играючи монтируется папки с хоста PVE в ваши контейнеры 4. Быстроподнятое упавшим не считается, а если не быстроподнятое, то можно словить"опять у тебя ничего не работает!" из соседней комнаты 5. Вы даже не знаете какой дистрибутив развернут в LXC контейнере с immich т.к. он создавался автоматически хелпер скриптом 6. У вас нет 6 млн рублей на покупку [видеокарты](https://forum.samohosting.ru/t/podbor-gpu-tpu/828/11) с аппаратной виртуализацией и возможностью независимого проброса в виртуалки **То LXC будет однозначно предпочтительней т.к.** 1. Выдает минимальный оверхед 2. Быстрее создается 3. Быстрее запускается **За счет того, что LXC в отиличе от KVM** 1. Использует одно ядро ОС 2. Использует общий файловый буфер 3. Использует общие файлы и процессы, изоляция производится при помощи механизма cgroups, как и в docker, между прочим 4. Ограничение доступных ресурсов RAM и CPU является скорее дополнительным функционалом (в PVE обязателен, а вот в чистом LXC/LXD при создании контейнера не требует указания RAM и CPU и даже диска т.к. может использовать общую ФС (тут у меня был прикол, когда 10 lxc контейнеров с docker исчерпали лимиты по inode хостовой файловой системы) 5. Создает контейнер из шаблона без фактической установки операционной системы, поэтому и нет cloudinit для CT 6. За счет пункта 3 я, например, пробросил в CT USB принтеры просто на уровне USB шины **И отличие при работе с устройствами, например, вы пробрасываете видеокарту в гостевую систему, то** - В qemu/KVM (VM) - устройство или полностью, если не умеет, или частично, если имеет соответствущие аппаратные возможности (например, для CPU это AMD-V и VTx, которые должны быть в процессоре и включены в BIOS) убираются из хоста и передаются в бинарном виде в гостевую систему, а гостевая система при помощи драйверов работает с этим устройством - В LXC (CT) - процессам в группе процессов, в простонародье называемыми LXC контейнером предоставляется доступ к логическому устройству (например видеокодер `/dev/dri/renderD128`), при этом само устройство обслуживаеся драйверами, находящимися в ядре хоста (а ядро то и там всего одно) **Например** Alpine linux в CT ходит за информацией не туда, куда следует и команда `top` показывает количество CPU и RAM хоста, а не те значения, которые вы указали в настройках контейнера ---
**Author:** ![vk\_hlab](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/v/ed8c4c/32.png) [@vk\_hlab](https://forum.samohosting.ru/u/vk_hlab)\ **Post date:** [24.Сентябрь.2025 03:17:21 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/3 "2025-09-24T03:17:21Z")
Возникает вопрос : а зачем тогда вообще proxmox такому пользователю, который не знает какая выбрана в LXC, когда с некоторых пор есть truenas с магазином приложений и их установке “по кнопке”? Думаю там вопрос шаринга видео также не заботит пользователя… ---
**Author:** ![vk\_hlab](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/v/ed8c4c/32.png) [@vk\_hlab](https://forum.samohosting.ru/u/vk_hlab)\ **Post date:** [24.Сентябрь.2025 03:22:42 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/4 "2025-09-24T03:22:42Z")
> [@KRom](#): > > например, для CPU это AMD-V и VTx, которые должны быть в процессоре и включены в BIOS) А можно подробнее…у интела то же есть такая технология..кажется iGPU-g до 11й версии проца… Получается, что проще купить проц, чем костылить бытовые дискретные видюхи mvidia… ---
**Author:** ![dr0n1k](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/dr0n1k/32/1211_2.png) [@dr0n1k](https://forum.samohosting.ru/u/dr0n1k)\ **Post date:** [24.Сентябрь.2025 06:28:46 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/5 "2025-09-24T06:28:46Z")
AMD-V и VTx - это инструкции процессоров для работы с виртуализацией, а вы говорите про iGPU - это интегрированный графический чип в процессор. Это абсолютно разные вещи. И да - для получения возможности транскодирования на том же самом jellyfin - покупать специально для это отдельно видео карточку не обязательно, встроенное видео ядро от интел достаточно не плохо справляется с этими задачами. Конечно если у вас стоят задачи куда выше уровнем, чем просто просмотр видео, то тут уже не обойтись без дискретной карты. ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [24.Сентябрь.2025 06:42:01 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/6 "2025-09-24T06:42:01Z")
> [@vk\_hlab](#): > > а зачем тогда вообще proxmox такому пользователю, который не знает какая выбрана в LXC И и наблюдаю тенденцию к переходу на truenas apps - [https://www.youtube.com/watch?v=LJY9KBbL4j0](https://www.youtube.com/watch?v=LJY9KBbL4j0) - [https://www.youtube.com/watch?v=gPL7\_tzsJO8](https://www.youtube.com/watch?v=gPL7_tzsJO8) - [https://www.youtube.com/watch?v=ZXit4mZetWA](https://www.youtube.com/watch?v=ZXit4mZetWA) Тем более, что 25 версия очень сильно прокачалась в плане приложений, а в плане высокой дисковой нагрузки в этих приложениях такой метод установки является самым эффективным ---
**Author:** ![vk\_hlab](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/v/ed8c4c/32.png) [@vk\_hlab](https://forum.samohosting.ru/u/vk_hlab)\ **Post date:** [24.Сентябрь.2025 07:20:08 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/7 "2025-09-24T07:20:08Z")
Меня примерно год назад, попробовав truenas only смутило: 1. Куча каких то юзеров с какими то правами и еще надо создавать юзеров…не разобраться…в каком месте дырки в безопасности 🙂 2. Очень круто они поступали с сообществом… Был кубернетис…нахрен, были какие то приложерия от сообщества…при обновлении версии вообще могут больше ее работать…хотя может сейчас все стабилировалось…развернул себе truenas изначально в proxmox.. И думаю - а зачем мне трунас нужен? Кроме как “гляделка за zfs”? А теперь вот думаю, что не зря пробросил в него родные материнке sata…теперь видюху прокинуь …и уже тупо в трунасе навертеть сервисы, которые требуют видюхи… ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [24.Сентябрь.2025 07:27:29 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/8 "2025-09-24T07:27:29Z")
> [@vk\_hlab](#): > > Куча каких то юзеров с какими то правами и еще надо создавать юзеров…не разобраться…в каком месте дырки в безопасности 🙂 Вот тут не понял ничего > [@vk\_hlab](#): > > Очень круто они поступали с сообществом… Был кубернетис…нахрен Да, их колбасит нехило так и это еще не конец, контейнеры у них с пометкой experimental. Я пробовал их куберовские приложения когда они k3s крутили локально. Конфигурация приложений от слова оверинжинеринг, деплоятся приложения целую вечность, свои приложения не поставить, в итоге они приняли правильное решение, что перешли на docker-compose здорового человека, но не допилили их до конца. Подобную ситуацию можно понять и простить если это был пет проект, но для вполне себе коммерческого продукта как минимум странно. > [@vk\_hlab](#): > > . И думаю - а зачем мне трунас нужен? Кроме как “гляделка за zfs”? Ну мне нравится 1. Удобное управление пулами и датасетами 2. Управление сетевыми шарами 3. Настройки создания снепшотов, сетевых синхронизаций 4. Мониторинг именно дисков, сети и прочего в режиме реального времени и в разрезе NAS ---
**Author:** ![vk\_hlab](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/v/ed8c4c/32.png) [@vk\_hlab](https://forum.samohosting.ru/u/vk_hlab)\ **Post date:** [24.Сентябрь.2025 07:29:28 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/9 "2025-09-24T07:29:28Z")
> **[GVTg\_Setup\_Guide](https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide)** > > Contribute to intel/gvt-linux development by creating an account on GitHub. Имел ввиду GVT-g: > .Intel GVT-g is a full GPU virtualization solution with mediated pass-through (VFIO mediated device framework based), starting from 5th generation Intel Core™ processors with Intel Graphics processors. GVT-g supports both Xen and KVM (a.k.a XenGT & a.k.a KVMGT). A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned…For client platforms, 5th, 6th, 7th, 8th or 7th SoC Generation Intel® Core Processor Graphics is required. For server platforms, E3\_v4, E3\_v5 or E3\_v6 Xeon Processor Graphics is required. ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [24.Сентябрь.2025 07:38:27 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/10 "2025-09-24T07:38:27Z")
> [@vk\_hlab](#): > > Имел ввиду GVT-g: Это уже скорее в ветку [по выбору GPU](https://forum.samohosting.ru/t/podbor-gpu-tpu/828/24) Идея интересная, но меня смущает 2 момента 1. я не знал, что есть зеоны с gpu, подозреваю, что найти их очень сложно и стоят неоправданно дорого 2. Вот это > # DISCONTINUATION OF PROJECT > > This project will no longer be maintained by Intel. > This project has been identified as having known security escapes. > Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project. > Intel no longer accepts patches to this project. В общем, опять 25, как всегда и да сколько же можно. Очередная попрытка виртуализировать GPU провалилась ---
**Author:** ![vk\_hlab](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/v/ed8c4c/32.png) [@vk\_hlab](https://forum.samohosting.ru/u/vk_hlab)\ **Post date:** [24.Сентябрь.2025 08:02:20 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/11 "2025-09-24T08:02:20Z")
> [@KRom](#): > > есть зеоны с gpu, подозреваю, что найти их очень сложно и стоят неоправданно Зеоны бу есть и их много и они не дорогие. Но видео ядро там несколько усеченное…я не зеоны имел ввижу уже А так да, бросили Интел эту технологию, только не копал почему, вы нашли… С другой стороны покодения еще не старые, а в части цены, так бу даже дешевле 🙂 но это уже буду уточнять в ветке прл cpu ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [24.Сентябрь.2025 08:50:25 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/12 "2025-09-24T08:50:25Z")
Предлагаю перевести обсуждение GPU [в эту тему](https://forum.samohosting.ru/t/podbor-gpu-tpu/828/25) Так как оно выходит за рамки данной темы ---
**Author:** ![Rid-lin](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/r/ccd318/32.png) [@Rid-lin](https://forum.samohosting.ru/u/Rid-lin)\ **Post date:** [27.Сентябрь.2025 10:51:01 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/13 "2025-09-27T10:51:01Z")
> [@KRom](#): > > 1. Ну понятно, что выкидывать ненужный функционал, с влучае с Alpine выкидывать нечего, надо добавлять только нужный, в случае Ubuntu/debian я находил скрипт, который удаляет лишне и оставляет только docker > 2. Смотреть в сторону легковесных альтернатив, например busybox заменяет кучу всего, dropbear вместо openssh и т.д. даже crond можно заменить на реализацию в busybox Кстати, для себя открыл давно DietPi на основе Debian, её можно на x86 запускать. Довольно маленькая ОС с небольшими и удобными TUI-скриптами, типа монтирования дисков, управления процессами, встроенным бекапом(через rsync), установкой/удалением ПО. Хранит почти все настройки установленного через её скрипты ПО в одной папке. Недавно переезжал с Hyper-V на Proxmox и миграция заключалась в “скопировать эту папку, после того как установил всё ПО которое было”. ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [06.Октябрь.2025 08:16:51 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/14 "2025-10-06T08:16:51Z")
Еще видео в тему [![](https://forum.samohosting.ru/uploads/default/original/2X/0/097db65f652aeabe433a6a463967801882487105.jpeg "Виртуализация KVM против LXC контейнеров. Что выбрать? | ServerFlow") ](https://www.youtube.com/watch?v=nOqoGCJ7pn4) ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [17.Октябрь.2025 12:36:15 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/15 "2025-10-17T12:36:15Z")
### А теперь разоблачение года **Миф №0: Матрешка вида PVE → LXC → Docker дает потерю производительности и виртуализацию внутри виртуализации** Нет смысла делать контейнер в контейнере в контейнере… и запускать докер внутри LXC т.к. это увеличивает накладные расходы и дублирует функциональность. **Разоблачение: Что LXC, что Docker под linux используют механизм cgroups/cgroups2, который позволяет изолировать процессы на на уровне ядра операционной системы** Для примера возьмем PVE 9 с LXC контейнером на основе alpine и 3 Docker сервисами ![image](https://forum.samohosting.ru/uploads/default/original/2X/0/06708c957fbe5ff93b853428b6d93da3ffe9d7ef.jpeg) Не знаю, зачем я включал там fuse, возможно для overlayfs, но есть nesting, который означает, что используется вложенность Заходим в контейнер ```bash vaultwarden:~# docker compose ls NAME STATUS CONFIG FILES komodo running(1) /srv/komodo/compose.yaml vw running(2) /srv/vw/compose.yaml vaultwarden:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5e733ff0019c ghcr.io/moghtech/komodo-periphery:latest "periphery" 2 weeks ago Up 6 days 0.0.0.0:8120->8120/tcp, [::]:8120->8120/tcp komodo-periphery-1 488bebf5e6bc vaultwarden/server:latest-alpine "/start.sh" 5 weeks ago Up 6 days (healthy) 0.0.0.0:3012->3012/tcp, [::]:3012->3012/tcp, 0.0.0.0:8884->80/tcp, [::]:8884->80/tcp vaultwarden 1a41d9d1b566 ghcr.io/openbao/openbao:latest "docker-entrypoint.s…" 5 weeks ago Up 6 days 8200/tcp vw-vault-agent-1 vaultwarden:~# ``` и видим, что там запущено 2 стека и docker контейнера Теперь переходим на хост Proxmox и вводим команду `systemd-cgls -c /lxc/150` ```bash root@pve-01:~# systemd-cgls -c /lxc/150 CGroup /lxc/150: └─ns (#7570) ├─ 1825 /sbin/init ├─ 3511 /sbin/getty 38400 console ├─ 3513 /bin/login -- кщще ├─ 3514 /sbin/getty 38400 tty2 ├─3831564 -sh ├─openrc.syslog (#8396) │ └─3414 /sbin/syslogd -t -n ├─openrc.dropbear (#8414) │ └─3470 /usr/sbin/dropbear ├─docker (#8655) │ ├─5e733ff0019c24245e762694f4cdd446da476905e3eb98657b0639892b2693cd (#8691) │ │ └─4775 periphery │ ├─488bebf5e6bc9acd213be890ee2f0efe7c18ccd96cf658d0b12297f6e791fe82 (#8673) │ │ └─4771 /vaultwarden │ └─1a41d9d1b566ad4e8ce50a44fe740e944ae23e1ed6c0d479603339222ec4a854 (#8709) │ ├─4773 /usr/bin/dumb-init /bin/sh /usr/local/bin/docker-entrypoint.sh agent -config=/etc/vault/agent-config.hcl │ └─4980 bao agent -config=/etc/vault/agent-config.hcl ├─openrc.docker (#8378) │ ├─3351 supervise-daemon docker --start --retry TERM/60/KILL/10 --stdout-logger log_proxy -m /var/log/docker.log --stderr-logger log_proxy -m /var/log/docker.log --respawn-delay 2 --respawn-max 5 --respawn-period 180> │ ├─3352 /usr/bin/dockerd │ ├─3373 log_proxy -m /var/log/docker.log │ ├─3374 log_proxy -m /var/log/docker.log │ ├─3647 containerd --config /var/run/docker/containerd/containerd.toml │ ├─4659 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 1a41d9d1b566ad4e8ce50a44fe740e944ae23e1ed6c0d479603339222ec4a854 -address /var/run/docker/containerd/containerd.sock │ ├─4660 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 5e733ff0019c24245e762694f4cdd446da476905e3eb98657b0639892b2693cd -address /var/run/docker/containerd/containerd.sock │ ├─4662 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 488bebf5e6bc9acd213be890ee2f0efe7c18ccd96cf658d0b12297f6e791fe82 -address /var/run/docker/containerd/containerd.sock │ ├─4899 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8884 -container-ip 172.18.0.2 -container-port 80 -use-listen-fd │ ├─4916 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 8884 -container-ip 172.18.0.2 -container-port 80 -use-listen-fd │ ├─4922 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 3012 -container-ip 172.18.0.2 -container-port 3012 -use-listen-fd │ ├─4927 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 3012 -container-ip 172.18.0.2 -container-port 3012 -use-listen-fd │ ├─4956 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8120 -container-ip 172.19.0.2 -container-port 8120 -use-listen-fd │ └─4963 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 8120 -container-ip 172.19.0.2 -container-port 8120 -use-listen-fd ├─openrc.crond (#8432) │ └─3504 /usr/sbin/crond -c /etc/crontabs -f └─openrc.networking (#7922) └─2372 /sbin/udhcpc -b -R -p /var/run/udhcpc.eth0.pid -i eth0 -x hostname:vaultwarden ``` Что мы тут видим? 1. PVE создал группу `/lxc` для контейнеров 2. В нее положил группу `150` с номером CT (и неймспейс 7570) 3. Там запущен `init` в качестве родителя всех процессов (в linux должен быть родительский процесс) 4. Там же запущен docker через openrc 5. Docker создал 3 группы для каждого контейнера и внутри запустил по init процессу `docker (#8655)`, тоже имеет свой неймспейс но не обображается утилитой Если кратко, то мы имеем следующую иерархию ```auto Host Kernel └── cgroup / namespaces (LXC) ├── init, getty, openrc... └── cgroup / namespaces (Docker) ├── vaultwarden ├── periphery └── bao agent ``` Ну и выполним еще одну команду на хосте ```bash root@pve-01:~# ps -p 881,3470,4771 -o pid,ppid,user,cmd PID PPID USER CMD 881 1 root sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups 3470 1825 100000 /usr/sbin/dropbear 4771 4662 100000 /vaultwarden ``` Мы видим тут следующее 1. ssh от рута на хосте (через который я сейчас и зпускаю данную команду) 2. ssh сервер dropbear внутри LXC контейнера. Он запущен от рута в контейнере, на хосте для безопасности к ID пользователя прибавляется 100000, таким образом, процесс, запущенный от root внутри контейнера на хосте является обычным пользователем и не обладает расширенными правами 3. vaultvarden внутри docker контейнера, который запущен тоже под рутом, поэтому и рекомендуется указывать user: UID:GID в докере, чтобы ограничить права процесса ### Что мы из этого поняли? LXC → Docker не порождает вложенную контейнеризацию и тем более, виртуализацию, не добавляет накладных расходов, Это только способ упорядочивания процессов и ресурсов, точно также как мы создаем каталоги в файловой системе или пользовуем `docker-compose` в место `docker run` Единственное, что мы тут имеем из накладного это вложенность файловых систем и независимые слои docker образов. Это значит, что `docker pull` в отдельных контейнерах будет скачивать образы каждый раз, а `docker compose pull` будет использовать общий набор слоев для всех стеков и условная ubuntu, использованная в качестве базового образа будет скачана 1 раз для всех контейнеров, которые запускаются на внутри текущего LXC контейнера На уровне ядра операционной системы эти процессы будут работать как обычные процессы, просто им будут доступны различные ресурсы и возможности ### Ну и напоследок, чтобы совсем взорвать мозг зуммерам Если в Docker в качестве entrypoint указать `/sbin/init`, предварительно сложив нужные файлы внутрь docker образа, то мы получим практическу полноценную “операционную систему” внутри докера, с ssh, и кучей сервисов, т.е. вместо кучи контейнеров можно в одном запустить и postgresql и redis и nginx и crond и свои сервисы, которые будут работать со всем этим. ---
**Author:** ![Vovec](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/vovec/32/78_2.png) [@Vovec](https://forum.samohosting.ru/u/Vovec)\ **Post date:** [18.Октябрь.2025 09:13:41 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/16 "2025-10-18T09:13:41Z")
Большое спасибо, что поделились с нами своим опытом, исследованием и выводами. Тема интересная и полезная. > [@KRom](#): > > vaultvarden внутри docker контейнера, который запущен тоже под рутом, поэтому и рекомендуется указывать user: UID:GID в докере, чтобы ограничить права процесса А можно какую-нибудь толковую ссылку или фразу для гугления, чтобы поподробнее почитать про этот момент? Это ваше [сообщение](https://forum.samohosting.ru/t/podklyuchenie-vneshnego-ssd-po-usb-i-ispolzovanie-ego-v-kontejnerah/862/5) по данному вопросу читал. ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [18.Октябрь.2025 13:04:20 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/17 "2025-10-18T13:04:20Z")
> [@Vovec](#): > > А можно какую-нибудь толковую ссылку Не знаю прям такие, чтоб в одном месте, но вот попросил ChatGPT кратко расписать (с толковым промптом) > **Развернуть** > > ### 1️⃣ Зачем задают пользователя в Docker > > По умолчанию процессы в контейнере запускаются от **root**. Это удобно, но небезопасно. Задание пользователя помогает: > > **Плюсы:** > > - Безопасность: ограничиваем права процесса, чтобы при взломе контейнера злоумышленник не получил root-доступ на хосте. > - Совместимость с томами: UID/GID пользователя в контейнере можно подстроить под хостовые права на volume. > - Контроль файлов: процессы создают файлы с правильным владельцем. > > **Минусы:** > > - Некоторые приложения требуют root (например, чтобы слушать порты \<1024, монтировать устройства, устанавливать пакеты). > - Нужно правильно настроить права на тома и папки внутри контейнера. > > * * * > > ### 2️⃣ Если пользователь не задан > > - По умолчанию процесс запускается от **root (UID=0)**. > - Все права на файлы и порты по умолчанию root. > > * * * > > ### 3️⃣ Как задать пользователя > > #### В Dockerfile > > ```auto > # создаём пользователя > RUN useradd -m myuser > USER myuser > > ``` > > или с конкретным UID/GID: > > ```auto > RUN groupadd -g 1001 app && useradd -r -u 1001 -g app app > USER app > > ``` > > #### В `docker run` > > ```auto > docker run -u 1001:1001 myimage > > ``` > > или по имени: > > ```auto > docker run --user app myimage > > ``` > > #### В Docker Compose > > ```auto > services: > app: > image: myimage > user: "1001:1001" > > ``` > > * * * > > ### 4️⃣ Особенности работы с volume > > - Если контейнер работает не от root, он может **не иметь прав на чтение/запись** в volume. > - Можно заранее поменять права на папки на хосте: > > ```auto > chown -R 1001:1001 /path/to/volume > > ``` > > или монтировать volume с правильными правами. > > * * * > > ### 5️⃣ Порты \<1024 (например, 80, 443) > > - Только root может слушать порты ниже 1024. > - Если пользователь не root, придётся: > - Использовать порты \>1024 внутри контейнера и проброс `-p 8080:80`. > - Использовать `CAP_NET_BIND_SERVICE` через `--cap-add=NET_BIND_SERVICE`. > - Или запускать процесс через root, а затем **drop privileges** к обычному пользователю. В итоге получаем, что задание пользователя в докере является одним из обязательным шагом харденинга, с другой стороны имеет ряд неудобств, с которыми надо будет мириться 1. Часто контейнер не может писать в волюм и надо руками создать его и прописать соответствуюие права 2. В vault-agent используется пользователь и у меня вечно проблемы с тем, что он не может сохранить файл с переменными окружения 3. В этом же vault-agent прокидываю `/var/run/docker.sock`, чтобы можно было пинать сервис при обновлении сертификато и пишет, что нет доступа, в итоге приходится запускать vault-agent с GID докера Но зато, злоумышленник, который взломает ваш сервис не сможет 1. Установить доп пакеты и ПО 2. При наличии проброшенной корневой ФС `-v /:/host` не будет полного доступа от имени рута 3. Мутить всякие мутки с системой типа дебага хостовых процессов, и изменения ФС (тут мы уже погражаемся в дебри харденинга докера) ---
**Author:** ![Vovec](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/vovec/32/78_2.png) [@Vovec](https://forum.samohosting.ru/u/Vovec)\ **Post date:** [18.Октябрь.2025 19:26:30 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/18 "2025-10-18T19:26:30Z")
Спасибо. Основной смысл ясен. Далее можно уже с конкретными интересующими контейнерами разбираться. Как всегда - нет предела совершенству 😉 ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [09.Ноябрь.2025 19:08:12 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/19 "2025-11-09T19:08:12Z")
Вылезла следующая проблема > [@Сломалась связка LXC-\>Docker с новыми версиями runc/containerd (например, Alpine v3.22, Ubuntu 24.04)](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245): > > Сегодня после обновления пакетов в alpine 3.22 (1/11) Upgrading alpine-conf (3.20.0-r0 -\> 3.20.0-r1) (2/11) Upgrading runc (1.3.0-r3 -\> 1.3.3-r0) (3/11) Upgrading containerd (2.1.3-r2 -\> 2.1.3-r3) (4/11) Upgrading pcre2 (10.43-r1 -\> 10.46-r0) (5/11) Upgrading containerd-openrc (2.1.3-r2 -\> 2.1.3-r3) (6/11) Upgrading docker-engine (28.3.3-r2 -\> 28.3.3-r3) (7/11) Upgrading docker-openrc (28.3.3-r2 -\> 28.3.3-r3) (8/11) Upgrading docker-cli (28.3.3-r2 -\> 28.3.3-r3) (9/11) Upgrading docker-cli-build… По ней, ожидаемо, заведен [баг](https://bugzilla.proxmox.com/show_bug.cgi?id=7006) Как оказалось, обсуждение данной проблемы тянется еще с 22 года и если перевести с немецкого на английский а с английского на русский, то получим следующее: > Если вы хотите запускать контейнеры приложений, например, образы Docker, рекомендуется запускать их внутри виртуальной машины Proxmox QEMU. Это позволит вам воспользоваться всеми преимуществами контейнеризации приложений, а также преимуществами виртуальных машин, такими как строгая изоляция от хоста и возможность живой миграции, что в противном случае было бы невозможно при использовании контейнеров. И далее идет [ссылка на wiki](https://pve.proxmox.com/wiki/Linux_Container), которую я привел в первой стройке данной темы (круг замкнулся), финита ля комедия. ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [18.Ноябрь.2025 19:37:47 UTC](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488/20 "2025-11-18T19:37:47Z")
В новом PVE LXC контейнеры стали еще ближе к докеру ![image](https://forum.samohosting.ru/uploads/default/original/2X/5/5dfd34a49c3d949823d9c880436b2146123a729a.png) Теперь можно задавать через интерфейс запускаемый процесс и переменные окружения, что является прямым аналогом соответствующих команд в Docker [Следующая страница](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488.md?page=2)