Тёплое и мягкое.

Docker, Podman, Kubernetes — 1 контейнер = 1 stateless сервис. К тому же, из-за отсутствия состояния (в идеале), оно также воспроизводимо.

LXD — полная система и stateful.

Выше всё правильно сказали, но дополню. Docker (и аналог Podman) — это технология для «контейнеризации» приложений, т. е. для того, чтобы приложения носили за собой свой рантайм. Можно считать, что один Docker-контейнер == один процесс (технически их может быть больше, но обращаться с ними нужно именно так). Docker-контейнеры не являются долгоживущими и в норме вообще не хранят никакое состояние, т. е. их rootfs умирает вместе с контейнером. Предполагается, что все ценные/долгоживующие данные нужно монтировать внутрь контейнера bind’ами.

А LXD — это контейнеры-виртуалки (играют ту же роль, что виртуалки). Они по умолчанию долгоживущие, внутри них запускается свой init и т. п. Аналогом этой технологии является systemd-nspawn.

Тёплое и мягкое.

Теперь понял.

Но всё же если не говорить про образ убунты в Docker и образ убунты в LXD, не для воспроизводимости, в чём отличия?

UPD: а, всё. Выше ответили.

Хорошо. Наверное действительно тёплое с мягким равняю, но всё равно почему-то уникумы умудряются их сравнивать и ставить LXC не в лучшем положении, и ещё использовать Docker буквально для всего.

но всё равно почему-то уникумы умудряются их сравнивать и ставить LXC не в лучшем положении, и ещё использовать Docker буквально для всего

лавров.жпг

Даже крупные, казалось бы, компании с популярными проектами совершают совершенно невыносимые глупости. Слёту взять контейнер от GitLab Omnibus — эталон того, как делать не надо. Жирнющий монолит на пару гигабайт, внутри которого запускается и GitLab, и база данных, даже небо, даже Аллах.

Так можно сделать в LXD, но подход OCI-контейнеров подразумевает, что база данных либо будет отдельным сервисом, а не внутри сервиса GitLab, либо её в контексте контейнеров вообще не будет (хорошая практика держать базу отдельно от сервисов где-то удалённо), а сам GitLab разделён по маленьким частям, с отдельным контейнером для каждой вещи, типа nginx, Sidekiq, Registry, Runner, etc. Винтики, которые можно крутить по отдельности.

Docker vs LXD(LXC)

Если юзкейс позволяет НЕ использовать docker, то не следует использовать docker.

Обоснуешь утверждение?

Тебе придётся поверить мне на слово. Учить азам сейчас не досуг.

Азам шизы? Ну, ладно. Как-нибудь обойдусь.

Иди лечись, друг мой. Всего хорошего, до свидания.

Докер раздувает системные требования (к оперативной памяти и кэшам, за счёт дублирования библиотек) и сильно усложняет flow обновления.

• Оригинальный подход Unix/Linux с динамической компоновкой: обновить дистрибутив штатным пакетным менеджером, иногда пересобрать прикладной софт.
• Подход со статической компоновкой, языкоспецифичными библиотеками и прочим новомодным пиннингом: обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости прикладного софта, пересобрать прикладной софт.
• Подход с Docker: обновить базовый образ, инвалидировать кэш сборщика, обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости прикладного софта, пересобрать прикладной софт.

Но более важная проблема в том, что никто из докеролюбов не заморачивается даже тем, что я написал. Берётся первый попавшийся базовый образ, на коленке методом «херак-херак» пишется докерфайл, после чего про базовую систему в принципе забывается, и когда следующий раз она получит обновления — большой вопрос.

Тот же вопрос возникает, когда софт уже написан и новые ревизии софта выкатываются в общем-то весьма редко. Вот ты отдаёшь себе отчёт в том, что даже если твой софт не обновляется, докер-образ всё равно нужно регулярно пересобирать, чтобы подтянулись обновления базовой системы? Уверен, что нет. Да и процессы CI/CD в 95% случаев построены так, что это сделать затруднительно, т. к. образы кэшируются на всех уровнях по ID коммита.

С другой стороны, в принципе, если квалификация команды такова, что процессы построены на от5.1сь, то нет никакой разницы, построены они на докере или на чём-то другом. Просто подход докера очень сильно упрощает, облегчает и порой даже рекомендует делать неправильно.

Допустим, у тебя десять команд, два десятка проектов с кучкой сервисов в каждом и никаких проблем с бюджетом на железо. Каким нужно быть идиотом, чтобы не использовать универсальный способ деплоя для всего этого?

никто из докеролюбов не заморачивается даже тем, что я написал

Этим занимается служба эксплуатации (исключая прибитые зависимости, конечно). Далее всё в молоко.

Этим занимается служба эксплуатации (исключая прибитые зависимости, конечно).

«Для этого есть отряд специально обученных людей.» ©

Посмотрел одним глазком на Kubernetes, Ansible etc.

Я так понимаю что в современном IT искоренилось понятие программы как скомпилированого кода, а стало как набор декларативно развёрнутых контейнеров, которые «вещь в себе». При всём этом легче оперативы докупить чем ликвидировать весь этот зоопарк.

Docker это flatpack на стеройдах, а lxc почти виртуалка, не хватает ядра и загрузчика.

Docker это flatpack на стеройдах

Стероидный Flatpak который носит ВСЁ с собой.

Сейчас создал контейнер в LXD и мне это очень понравилось, всё стало буквально из коробки, для непривелигилированого контейнера просто добавил юзера в группу lxd.

Ну да, для Докера группа ldx не играет роли. Там группа docker. Может дело в этом? Хи-хи.

Стероидный Flatpak который носит ВСЁ с собой.

Да, никто не запрещает запускать несколько копий докеризованного приложения. В докере необходимо держать все данные вне контейнера.

Допустим, у тебя десять команд, два десятка проектов с кучкой сервисов в каждом и никаких проблем с бюджетом на железо. Каким нужно быть идиотом, чтобы не использовать универсальный способ деплоя для всего этого?

Докер — это не способ деплоя. Это способ поставки.

Этим занимается служба эксплуатации

«После нас — хоть потоп»

Далее всё в молоко.

Потому что ты скозал?

Типа того.

Докер — это не способ деплоя. Это способ поставки

Спасибо, Капитан Выпендрёж.

Потому что ты скозал?

Наоборот, потому, что ты лепишь херню.

Спасибо, Капитан Выпендрёж.

Ну если ты неспособен без внешней помощи связать три факта в логическую цепочку, то я не виноват. Можешь считать, что «выпендрёж».

Наоборот, потому, что ты лепишь херню.

Аргументация уровня «бог».

Ты главный аргумент проигнорировал и начал кривляться.

Сложно компенсировать ваш дефицит образования. Позиция ваша очень похожа на синдром утёнка.

Ты по делу так ничего и не сказал, лишь «кококо». Не можешь свои арменты привести против, так попробуй хотя бы мои опровергнуть.

Докер — суперудобная штука. Легко тетсировать, легко деплоить, легко конфигурировать, легко масштабировать. А локально чот запустить и подебажить — вообще красота. На этом фоне, вышеназванные недостатки — просто мнимая херня на постном масле.

Сдаётся сне, ты просто поехавший ретроград, который докер даже и не пробовал.

На самом деле люди ответили на ваши вопросы.

С другой стороны, в принципе, если квалификация команды такова, что процессы построены на от5.1сь, то нет никакой разницы, построены они на докере или на чём-то другом. Просто подход докера очень сильно упрощает, облегчает и порой даже рекомендует делать неправильно.

Вот это как раз ваш случай. О чем вы и радостно сообщаете:

Докер — суперудобная штука. Легко тетсировать, легко деплоить, легко конфигурировать, легко масштабировать. А локально чот запустить и подебажить — вообще красота. На этом фоне, вышеназванные недостатки — просто мнимая херня на постном масле.

«Мнимая херня на постном масле» это грамотно выстроенный процесс эксплуатации, в котором учтены многие важные детали.

Выводы из воздуха, типичная лоровская аналитика.

Но, ок, допустим, у меня команда — эталонная толпа наиконченейших раздолбаев, каким образом это камень в огороде докера? Демагогия донного уровня.

Демагог это вы. Вам же сказали, что использование докера имеет смысл в определенных условиях. Когда условия более строгие докер уже не подходит. Это просто инструмент со своими достоинствами и недостатками.

Нет. Тред начался с клоунского высера:

Если юзкейс позволяет НЕ использовать docker, то не следует использовать docker

Я призвал автора к ответу, он ответить оказался не способен.

Я призвал автора к ответу, он ответить оказался не способен.

Я попытаюсь. У автора есть какая-то боль, в которой кто-то обязательно должен быть виноват. Почему бы и не докер, на самом-то деле.

Стероидный Flatpak который носит ВСЁ с собой.

А еще работает под рутом, ковыряется в iptables, и делает прочие непотребства

flatpak

А еще работает под рутом

O RLY?

https://github.com/flatpak/flatpak/issues/1576

Надо бы этот пост сохранить и показывать заказчику, который вдруг начинает топить за докер.

Кроме шуток, ты хорошо все описал.

Кстати, ты уже не в КрасноШляпе?

Кстати, ты уже не в КрасноШляпе?

Нет, я никогда не работал в RH.

А хотел бы?

Возможно.

Мнение новичка:

Для новенького DOCKER показался сильно замудрен в реализации. Гораздо проще было быстро все поставить в контейнере при помощи LXC.

Понимаю, что, возможно, я заблуждаюсь, и для проектной команды лучше докер. Но для меня ближе LXC - это же А-ля CHROOT. Запустил то что тебе нужно в изолированной среде, и все на месте, хотя бы взять тот же SYSTEMCTL.

А в реализации идей бизнеса отталкиваюсь от того, что главное чтоб было удобно самому администратору, быстро и без потери качества все реализовывать :-)

Опять же зависит от задач. У меня ныне в докере питоньи комбайны, которые тянут за собой кучу зависимостей, в который гарантировано что-то не заработает при установке на хост. LXC для Ubuntu Server, чтобы не тянуть софт и конфиги сервера на хост. Так что прекрасно распределено для своих функций.