LXC контейнеры для отдельных сервисов

Proxmox
1

Использовать отдельно контейнеры под каждый сервис или все сервисы закинуть в один конейнер или ВМ с докером - тут каждый решает для себя сам. Что удобнее и привычнее то и использует.

Хочу разобраться именно в производительности.
Есть ли разница в производительности между сервисом установленым в отдельном контейнере без докера, с докером специально под этот сервис и с докером со всеми сервисами сразу?
Например, некоторые сервисы в скриптах Proxmox helper scripts устанавливаются именно в докере.
Понимаю что для домашних сервисов с 3-5 пользователями вообще нет никакой разницы как и где устанавливать все.
Вопрос сугубо спортивный. :person_cartwheeling:

1 лайк
2

Я уже отвечал на данный вопрос тут: LXC vs VM для докера и не только

Если кратко, то особой разницы нет, но есть несколько, моментов

Внимание! Дальше идет лонгрид:

Вот мой кластер с 42 запущенными LXC контейнерами и еще 15 потушенными

image
image1746×539 135 KB

Начнем с того, что Proxmox не рекомендует LXC как таковые, обоснование почитать по ссылке выше

По ресурсам

  • CPU - современные системы контейнеризации и паравиртуализации практически не накладывают доп. нагрузки, особенно, если основное вычисление происходит в юзерспейсе с минимальным количеством системных вызовов
  • ФИЧИ CPU и Ядра - тут надо учитывать, что не все можно запихнуть нормально в матрешку (PVE → LXC → DOCKER) например, Podman у меня не захотел работать без привилегированного режима. Поэтому, 1 вариант самый надежный, 3 может потребовать снижения безопасности, 2 посерединке - можно отключать точечно.
  • RAM - в целом, я бы не сказал, что сильно влияет, особенно если это не VM, то оверхеда и резервирования нет практически
  • Сеть - docker-proxy снижает производительность, насколько, + проблемы с мультикастом + с IPv6, перевод traefik и consul на network_mode: host сразу решило все мои проблемы, далее кластеризируемые сервисы типа openbao я сразу запускал в этом режиме. OST вот с такими результатами на 1 Ядре с проксированием выдал 32% CPU, с network_mode: host 25%, но это на 2.5 гигабитах
  • HDD - сложный вопрос, я бы не сказал, что имеет значение, но испортить при желании можно. Там и с LXC уже слоеный пирог, а если добавить докер, то добавляется немного, но в Linux работает довольно таки быстро, в MacOS очень долго работало из рук вон плохо, сейчас вроде обещают на уровне Windows, т.е. на 2 головы хуже, чем в Linux
  • Гостевая OS - надо понимать, что она LXC контейнер не работает сам по себе, там есть куцая, но система, пусть и без ядра, но init все равно работает, в 1 и 2 варианте при большом количестве сервисов это может иметь место, например переезд с Ubuntu на Alpine для одного из моих сервисов позволило
    • CPU в простое 2% → 0.2%
    • RAM 350MB → 120MB
    • HDD 3.5ГБ → 1.5ГБ

По типам развертывания

Отдельные контейнеры без докера

  • В теории производительность на уровне 99-100%, но обслуживать сложнее в плане разворачивания и обновления, в репозиториях не всегда есть актуальные версии, если ставить руками, то надо обновлять как-то, тот же Proxmox-Helper-Scripts это самостоятельно делает, но что если скрипт упадет? Что он делает там? Где когфиги? Откуда и куда качает?
  • Надо понимать, что сам LXC контейнер что-то да и весит, я лично пока перешел на alpine как раз таки для минимального оверхеда, пытался еще уйти с docker на podman еще для снижения издержек, но не завелось

Отдельные контейнеры с докером

  • При использовании alpine оверхед минимальный, производительность чуть ниже, за счет дополнительных слоев контейнеризации
  • Удобно управлять средствами самого Proxmox, есть тулзы типа Pulse
  • Не используется переиспользование системных файлов и слоев в docker, это значит, что если используется ubuntu:latest, в качестве базового образа то тут она будет скачана каждый раз, а в 3 случае только 1
  • Можно использовать network: host

Один LXC контейнер с кучей докеров

  • Оверхед операционки контейнера минимальный
  • Переиспользование слоев докера
  • Легко добавлять новые сервисы
  • Без кубера и подобных сложно разворачивать на нескольких серверах
  • Proxmox тут не особо то и нужен уже

Я бы расставил рейтинг следующим образом

  1. много Alpine LXC без докера
  2. 1 ubuntu/alpine LXC + много docker
  3. много alpine LXC + docker
  4. много ubuntu LXC + docker

Итого

  • Высоконагруженные сетевые и дисковые лучше на хосте или в одном LXC без докера, типовые приложения в докере будут терять меньше фоновой нагрузки самой операционки
    • Qbittorrent я развернул в LXC + Alpine (alpine еще хороша тем, что там как правило, самый свежий софт, особенно в edge + ее очень легко обновлять), не не скажу в числах, но больше стал раздавать.
      image
      image271×784 63.4 KB
    • Основную доп. нагрузку при множестве LXC контейнеров будет иметь сама операционка внутри LXC контейнера, она может быть более существенной, нежели потери при “обматрешкивании” самого приложения
  • Множество LXC контейнеров надо как-то поддерживать, у меня для этого используется связка Ansible (Semaphore UI) и Komodo поверх Forgejo (GIT репозиторий), однозначно с 1 контейнером и кучей docker управлять будет проще
  • Если выбирать 3 вариант, то можно посмотреть в сторону runtpi или приложений внутри самого TrueNas
  • Актуальные версии софта чаще всего есть в docker, далее идет alpine, потом ubuntu и замыкает debian, ну можно еще федору рассмотреть, но меня тошнит от центоса и федоры.
  • Я топлю за Alpine еще и потому, что там сам оверхед очень маленький и обновление с одной версии на другую очень быстро происходит, есть и rolling версия. С кучей LXC контейнеров на ubuntu тот еще гемог обновлять с одгого LTS релиза на другой - время обновления выше, а шанс словить проблему больше.

UPD:
По поводу alpine linux хочется добавить несколько моментов

  1. musl вместо glibc имеет свои тонкости
  2. плохо работает с cgroups2
  3. Воловина консоли на busybox

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

7 лайков
3

вот это поворот…самый большую “дырку в безопасности” вы сделали непосредственно в proxmox?

или уточните, почему шаринг своих файлов через торренты “всем подряд” не считаете дырой?

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

4

Ну не proxmox, а в непривилегированном контейнере под непривилегированным пользователем в окружении достаточно урезанной Alpine Linux

При этом каталог с контентом подмонтирован в сам LXC контейнер через mp

что есть своих файлов и всем подряд и чем оно лучше в VM?

Никто не запрещает вынести LXC контейнер в отдельную сеть, причем, я даже больше скажу, медиа каталог у меня монтируется через NFS, который работает в отдельном сегменте сети, к которому не имеет доступа ни один контейнер, но 1 виртуалка (и то не на долго, я говорю про PBS сервер т.к. планирую его вынесли в LXC)

У меня в TrueNAS есть несколько пулов, в том числе один состояит из 1 диска и называется media и из он же по частям раздается потребителям и датастор video примонтировал в виде каталогв в qbt контейнер.

Если продолжить тему LXC vs VM для докера и не только - #12 от пользователя KRom, то базово, LXC контейнер

  1. не дает доступа к управлению сетевым интерфейсом
  2. не имеет прмого доступа в NASу
  3. не дает установить модули ядра

Потенциально из LXC контейнера убежать проще, чем из полноценной VM, но если заняться хотябы минимальным харденингом, настроить отдельную подсеть и файрвол проксмокса, не ставить лишних программ туда и держать актуальные версикии ПО, то я не думаю, что все хакеры мира захотят сломать ваш домашний сервер через qbt, пройдя через фаервол, cgroups, apparmor

2 лайка
5
  1. предполагаю, что торенты дают высокую нагрузку на операции и чтения и записи…надо ли все это прогонять через truenas? другими словами, почему не просто хард из проксмокс?
  2. еще вспомнил , что таким образом я оставляю резерв sata портов родных (которых всего 6, а hdd уже 4 штуки ), которые “проброшены” все в трунас, т.к. находятся на одном PCI.
6

И да и нет, с точки зрения харденинга опять же, торренты качает отдельный контейнер, в самом начале я туда еще ставил самбу и jellyfin, но мне это не понравилось, в итоге у меня схема выглядит так

image
image631×732 14.5 KB

Truenas пользую как

  • ГУЙ и показометр
  • Настройщик Шар
  • NFS шара для всех нод в кластере

Хранит не только видео, но и остатки оффлайн музыки и аудиокниги

Сервисы, которые жестко используют диск храню на одном сервере, недавно для этого еще приобрел оперативку для апгрейда 16 → 32 ГБ, чтобы выделить чисто трунасу 16ГБ без всяких балунингов

Ну и тюнил NFS еще в придачу.

В последнее время jellyfin, что-то не хочет индексировать на компе смотрю просто с примонтированной по NFS шаре

Ну т.е. удобство победило производительность

1 лайк
7

понял только то, что не заморачивались или не было побудительных причин, анпример, как меня - HDD-помойки вынести на NVME-SATA переходник, чтобы оставить резерв “надежных” sata портов под последующее добавление хардов для пулов truenas.

Поэтому, делаю вывод, что я также могу пойти своим путем, например, по инструкции тут: Помощь в настройке HDD как хранилища для сервисов на Proxmox + LXC (Runtipi)

8

У меня сейчас диски проброшены в truenas не через PCI контроллер, а по одному, тем более, что сейчас подключены по USB, но на следующий год хочу минипк заменить на mini ITX плату именно под медиа сервак с truenas

Ну и еще думаю сделать раскатку fstab при помощи ansible, он будет одинаковый для всех серверов, т.к. даже на медиа ноде все равно по NFS монтируется.

А так да, явных причин не было, но я 100500 лет сидел на ручном шаринге путем правки smb.conf и /etc/exports + поднимал самбу на медиа контейнере с торрентами (на старте) и просто хотелось забить на все и делать клац клац мышкой

Я вообще ставил truenas, чтобы делать клац-клац, реально задолбался править уродские конфиги самбы, восстанавливать шары после обновления операционки, писать на баше скрипты для создания снепшотов zfs, какие-то уведомления настраивать, иметь 100500 программ под каждый тип шары, в общем, одной ногой уже наступил на Synology, но хотелось больше гибкости и не платить кучу денег за старое железо.

В итоге в TrueNAS собрал пулы, создал пользователей, настроил шары, настроил лимиты по датасетам и смотрю как оно все красиво отображется, правда, я начинал с core на FreeBSD, а потом понял, что это бесперспективная ветка и развернул Scale версию и был неприятно удивлен тем, что выпилили кучу протоколов из ядреной поставки, например, fto (который не пользую), tftp, webdav, afp, rsync, с приложениями не так прикольно уже настраивать шару, тогда уже можно и

по этому сценарию пойти

1 лайк
9

Какая дикость :slight_smile: когда не купил еще nvme sata платку, то по usb подключил только proxmox загрузочный zfs два ssd, прокинув кабель внутрь корпуса, что ssd снаружи не болтались…ни smart ни иной инфы по usb не отдают диски…
У меня регулярно сыпался rpool… Один диск все время…сейчас переключил на sata, теперь второй ssd ужел в ошибки… Восстановил…вот вроде пока работают…

10

Интересен ваш взгляд на критерии, вроде все топят за миники…хотя не понятно зачем :slight_smile: как понял, не хватает мощи проца запаянного?

Вот сейчас я уже думаю развести не один сервер…если все равно надо пользовать видюху и если мне rx 550 не подойдет, то может:

  1. 10 ядерный зеон, 128 гб озу прислонить к моей видюхи rx 7900 gre с 16 Гб озу…чтобы кроме игр баловаться llm
  2. Купить проц со встройкой…и ECC памятью…чтобы за цену какой нить 2080бу получить энергоэффективный скрвер…но вот мне кажется, что все улетит за 50 тыр :slight_smile:
11

Не понято прям именно сейчас - зачем вам proxmox :slight_smile: наклацали бы полностью на трунас и опыт был бы ваш бесценен …вот я сейчас побаиваюсь переходить еа трунас с приложениями…после их выкрутасов… Наверно и с озу можно оптимальней балансировать т к всем будет.щаведовать трунас

12

Опять же, заадачи у всех разные, а мы уже ушли в сторону
Во первых я пользую proxmox для управления самим truenas :laughing:
Во вторых помимо наклацать приложения в truenas

  1. Приложения из каталога truenas ставятся неплохо, кастомные же максимально корявые
  2. Непонятно как этими приложениями управлять через CI/CD
  3. У меня помимо сервера с truenas есть еще 4 узла в кластере, на них тоже ставить truenas? или зачем 4 если можно взять 1 мощный 4U сервак?
  4. Я тут расписываю про встроенное бекапирование сервисов, подкладывание сертификатов и секретов из волта, деплой сервисов из гита при помощи komodo, а в ответ “наклацали бы полностью на трунас”
1 лайк
13

Ну это мой проверочный вопрос, вдруг рецепт получу готовый :slight_smile: спасибо за терпеливые ответы :slight_smile:

14

А может быть какой-то рецепт? По мне так truenas apps на уровне runtpi, супер-пуппер-ОС и прочих продуктов, по быстрому запуску приложений
Вот мои приложения в truenas

image
image971×432 104 KB

iperf3 делал как кастомное, чтобы проверять прямую скорость до truenas
www - это nginx для раздачи статики с рейда

С чем столкнулся при этом

  1. Пул для самих приложений на HDD рейде, я привык, что у менясервисы на nvme, а данные большие уже на HDD
  2. Для кастомных приложений нельзя задать иконку, описание и версию, т.к. обновление кастомного приложения это обновление конфигурации, а не докер образ
  3. Полностью кастомные приложения на основе docker-compose не пробовал пока
  4. По умолчанию, truenas не пользует мост, тот же nginx у меня висит на порту 8000 т.к. 80 занят самим трунасом, что не очень удобно, но терпимо, но это же docker, а не lxc или vm, для них надо создавать мост
  5. Видел в интернете инструкцию, как поднимать приложение на отдельном IP, там создается vlan интерфейс самого truenas и на него навешивается приложение уже
  6. Работа с сертификатами очень странная, sftpgo можно подсунуть сертификат из truenas, а кастоному nginx - нет
  7. В теории, можно попробовать добавить приложение nginx proxy manager и вместо публикации портов приложений ходить от NPM в приложения по внутренней сети, но я не уверен, что там сработает, хотя… там есть пункт “expose port for inter-container communication” т.к. может оно и сработает
    7.1. Меняем порт для веб интерфейса truenas на 8080 и 8443
    7.2. Ставим NPM как приложение и запускаем на 80 и 443 портах
    7.3. Публикуем порты сервисов для inter-container
    7.4. В NPM создаем поддомен, отправляем трафик на нужный внутренний порт сервиса
    7.5. В NPM добавляем свой же домен трунаса и редиректим порты на 8080, чтобы можно было на трунас ходить по 80 и 443
    7.6. В случае падения NPM у нас остается вспомогательный доступ по портам 8080 и 8443
    7.6. либо же вообще поднимаем еще один IP и веб интерфейс трунаса навешиваем на 1 IP а NPM на другой
  8. Меня смущает, что они несколько раз меняли архитектуру приложений, при обновлении у меня слетали старые приложения, syncthing у меня одно время не хотел обновляться т.к. была проблема в приложении, в общем, не самая стабильная вешь
  9. Под приложение создается скрытый датасет, с ним как-то тоже надо работать
  10. Ну и не разбирался с тем, как выносить приложения в DMZ и делать сложные сетевые схемы, как это легко делается в proxmox
15

С этим согласен… Вероятно выход в том, чтобы truenas - отдельная железка с gpu и с пулом его приложений, завязанных на nas функционал, отдельно железка с openwrt роутером, торрент качалкой, отдельно комп с мощной видюхой

16

Рекомендую ознакомиться с комментарием LXC vs VM для докера и не только - #15 от пользователя KRom на тему запуска docker внутри LXC

1 лайк