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

Proxmox (7.1) и Docker: LXC против VM, Proxmox Виртуальная Среда

twl

Guest

17.02.2022 22:01:00

Официальные советы по PVE рекомендуют размещать контейнеры Docker в виртуальных машинах. (LXC против LXD против контейнеров Proxmox против Docker) Также здесь, на форуме, есть множество постов, которые советуют использовать виртуальные машины. Однако существует множество руководств по использованию CT (LXC) для запуска контейнеров Docker на Proxmox. Какова же причина, по которой рекомендуют использовать виртуалки? Вот некоторые плюсы и минусы, которые я смог придумать, и буду рад помощи сообщества в составлении поста с обоснованной рекомендацией для различных случаев использования. Docker в CT (LXC) плюс: менее ресурсоемкие резервные копии PBS: функциональность восстановления из одного файла минус: возможно, меньше производительности? (некоторые утверждают, что производительность плохая) Безопасность: менее изолировано, чем ВМ (но все же более изолировано, чем стандартная установка Docker) некоторые контейнеры могут не работать и требуют опции "привилегированный контейнер" (проблема с безопасностью) резервные копии PBS занимают больше времени. Docker в ВМ плюс: максимальная изоляция. Docker работает, как при нативной установке. Резервные копии PBS быстрее. минус: тяжелая нагрузка на ресурсы, особенно если нужно создать по ВМ для каждого контейнера Docker. Резервные копии с PBS: можно восстановить только целую ВМ, а не отдельные файлы. Вы согласны с моим списком? Что я забыл упомянуть? Почему вы рекомендуете или не рекомендуете использовать CT для запуска Docker? Мне интересно ваше мнение, и я обновлю пост соответственно. Мой личный сценарий: у меня довольно ограниченное оборудование для домашней лаборатории PVE (процессор i5 и 20 ГБ ОЗУ) и вторая машина настроена как PBS. По этой причине я хочу минимизировать количество ВМ и использовать CT, когда это возможно. Есть несколько образов Docker, которые я хотел бы использовать, все это сравнительно легковесные приложения. (Wireguard, duckdns, nginx-proxy-manager, Heimdall и, вероятно, еще несколько) В настоящее время все они находятся внутри ВМ Ubuntu 20.04. Это значит, если что-то пойдет не так с моей ВМ Ubuntu, все контейнеры Docker будут отключены. В идеале мне хотелось бы иметь отдельный CT для каждого Docker-образа. Как вы думаете, имеет ли это смысл? Это идиотизм? Что вы рекомендуете?

Helmut101

Guest

13.07.2022 18:06:00

Извини, но использование XFS поверх ZFS — это не использование ZFS. Также ты не пересек другой континент на велосипеде, если сидишь на нем, пока летишь на самолете. Цитирую себя: но на машинах нижнего уровня это значительно медленнее, чем использовать ZFS непосредственно на хосте. Я провел обширные тесты производительности с pveperf и fio, и разница была почти нулевой, например, по сравнению с ext4 на стандартном аппаратном Raid1. Но, похоже, ты защищаешь что-то другое, и я не буду продолжать, поскольку мы, похоже, говорим о разных вещах.

Helmut101

Guest

06.07.2022 12:17:00

Я могу подтвердить, что ZFS+Unprivileged LXC + Docker работает безупречно. См. здесь. У меня 7 непривилегированных LXC с Docker, вложенным в каждый из них, всего около 25 контейнеров Docker, работающих на ZFS-томах, отформатированных как XFS. Никаких проблем за последние 2 года. Даже более тяжелые контейнеры (Gitlab, Nextcloud и т.д.) работают без проблем. Я также не замечаю проблем с производительностью, средняя загрузка моего процессора составляет 1-2%, так как каждый процесс выполняется на хосте, а большинство процессов большую часть времени просто простаивают. Я предполагаю, что с полноценными ВМ ситуация была бы другой.

LnxBil

Guest

13.07.2022 10:14:00

Итак, ты не используешь классный ZFS-Backend для Docker, который намного медленнее, чем использование ZFS напрямую, и у тебя не будет таких крутящих функций, как слои образов Docker в снимках и автоматическиеdatasets для томов Docker.

Helmut101

Guest

13.07.2022 14:57:00

Итак, ты не используешь замечательный ZFS-Backend для Docker, который, кстати, гораздо медленнее, чем использование ZFS напрямую, и ты не получишь классные функции, такие как слои образов Docker в снимках и автоматические наборы данных для томов Docker. Насколько мне известно, это медленнее только для сборки образов Docker — это касается, например, Gitlab Runners и тому подобное — я обычно собираю образ раз в месяц (когда выходят обновления). Если ты разрабатываешь программное обеспечение, я согласен и предлагаю использовать виртуальную машину. По моим наблюдениям, разница в скорости чтения незначительная. Я никогда не замечал времени ожидания ввода-вывода. Что касается снимков: ты можешь использовать ZFS Snapshots. Вновь, если ты разрабатываешь образы Docker с множеством слоев, лучше использовать виртуальную машину. Мой ответ был только на твое утверждение: которое не соответствует действительности.

LnxBil

Guest

13.07.2022 15:17:00

Извини, но использование XFS поверх ZFS — это не использование ZFS. Ты также не пересек другой континент на велосипеде, если сидишь на нем и летишь на самолете. Судя по твоему описанию, ты просто пользуешься черным ящиком (им здесь и является ZFS), который не имеет присущих особенностей, кроме того, что он блоковое хранилище. Может быть, я неправильно выразил свои мысли, так что попробую еще раз: если ты запускаешь Docker на системе без ZFS (или BTRFS), ты всегда используешь какой-то вид оверлейной файловой системы для хранения изменений слоев. Это по сути не неизменяемо и требует работы при каждом доступе к файлу. Docker-тома также являются прямыми файлами, которые нельзя снапшотить по каждому тому. В то время как с ZFS существуют неизменяемые слои (включая тома, если нужно) твоих контейнеров, которые уже являются снапшотами, доступными без каких-либо оверлеев и с эффективным использованием пространства (до применения сжатия или дедупликации). Тома представляют собой наборы данных ZFS и, следовательно, могут быть снапшотированы, что отлично подходит, например, для миграционных тестов. Просто сделай снапшот, клонируй и запусти свой стек с новым клоном без копирования файлов, простоя или чего-либо еще. У тебя также есть другие функции, такие как квоты и резервирование, которые доступны напрямую для Docker-томов. Вот что я имел в виду, когда говорил "не могу сделать это в контейнерах LX©". Наборы функций различны. Я тоже использую твой подход с черным ящиком, но на более слабых машинах он значительно медленнее, чем использование ZFS непосредственно на хосте.

martin_j

Guest

23.07.2022 00:15:00

Не предполагаю, что у тебя что-то вышло с совместным использованием привязок. Кажется, не удается заставить это работать в LXC (привилегированном или непривилегированном) , но в виртуальной машине работает. Также сталкиваюсь с той же проблемой, когда использую Docker из Snap, так что подозреваю, что это связано с пространством имен или чем-то подобным (https://forums.docker.com/t/docker-from-snap-on-ubuntu-cant-create-a-shared-bind-mount/119981). Легко проверить. Не работает # docker run -it --rm -v /tmp:/tmp:shared alpine ash docker: Ошибка ответа от демона: путь /tmp смонтирован на /, но это не совместный монтаж. ERRO[0000] ошибка ожидания контейнера: контекст отменен. Работает (ну, очевидно, также нужно проверить, что директория /tmp.shared между хостом и контейнером Docker, но это не провалилось на первом этапе) # docker run -it --rm -v /tmp:/tmp:shared alpine ash / #

Helmut101

Guest

23.07.2022 06:52:00

Я не использовал совместимые привязки. Вы включили FUSE в параметрах контейнера Proxmox (в разделе Функции)? Ссылка, которую вы дали, относится к виртуальным FUSE-привязкам, созданным внутри контейнера и связанным с хостом. Если это проблема, я думаю, что это может не иметь отношения к ZFS, так как у вас та же проблема с привилегированным LXC.

martin_j

Guest

23.07.2022 09:35:00

Ах да, извиняюсь, надо было сказать, что у меня была выбрана опция предохранителя. Нет, я почти уверен, что это не связано с ZFS, так как такая же проблема есть и на pve, который не использует ZFS. Ну, ладно, попробую еще несколько вариантов, а если не смогу заставить это работать, просто использую VM (что, конечно, печально). Всем привет!

jaskohl Guest	#10 0 23.05.2023 00:40:00 Я голосую за виртуальную машину с BurmillaOS. С уходом RancherOS появилась замена под названием BurmillaOS. Это, по сути, форк rancheros с продолжением разработки.

Читают тему

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