В чем разница между Docker, LXD и LXC [закрыто]
В чем разница между Docker, LXD и LXC. Они предлагают одинаковые услуги или разные.
Нет, LXC, Docker и LXD не совсем одинаковы. Короче говоря:
LinuX Containers (LXC) — это метод виртуализации на уровне операционной системы для запуска нескольких изолированных систем Linux (контейнеров) на одном управляющем хосте (хосте LXC).
докер
- Docker, Inc
- контейнерная система, использующая контейнеры LXC
- так что вы можете: Build, Ship, and Run Any App, Anywhere http://www.docker.com
- от Canonical, Ltd
- использование системы контейнер изготовления контейнеров Lxc
- так что вы можете: run LXD on Ubuntu and spin up instances of RHEL, CentOS, SUSE, Debian, Ubuntu and just about any other Linux too, instantly, . http://www.zdnet.com/article/ubuntu-lxd-not-a-docker-replacement-a-docker-enhancement/
Докер против LXD
- Docker специализируется на развертывании приложений
- LXD специализируется на развертывании (Linux) виртуальных машин
Незначительная техническая записка
- Установка LXD включает в себя программу командной строки с совпадающим названием lxc http://blog.scottlowe.org/2015/05/06/quick-intro-lxd/
Это изображение может помочь вам понять основное различие между ними:
Их объединяет то, что все эти 3 технологии связаны с контейнерами.
Контейнеры — это легкий механизм виртуализации, который не требует настройки виртуальной машины на эмуляции физического оборудования. В Linux, что они имеют в общем , является функция ядра , используемая: cgroups , namespaces(ipc, network, user, pid, mount) . Они также пытаются создать более безопасные среды путем создания непривилегированных контейнеров и интеграции с такими функциями безопасности, как selinux . Эти технологии экспортируют API для лучшей интеграции с другими программами.
LXD и LXC
Эти два объединяют одну семью, где:
- lxc : пользовательский интерфейс для функций локализации ядра Linux. Это парень, который управляет пространствами имен Kernel, профилями Apparmor и SELinux, Chroots, возможностями Kernel и прочими связанными с ядром вещами.
- lxd : контейнер «гипервизор». Он состоит из демона (lxd), интерфейса командной строки (lxc) и плагина OpenStack. Этот парень был разработан для обеспечения большей гибкости и функциональности для lxc, хотя он все еще использует его под капотом.
По сути, автономное пользовательское пространство ОС создается с изолированной инфраструктурой. lxc более непосредственно лежит в основе функций ОС для работы в сети и хранения данных, чем Docker.
Вы создаете много виртуальных машин, у которых есть пользовательское пространство и изоляция ядра, но они не являются полными виртуальными машинами, так как они не работают с разделенными ядрами, и не паравиртуализируются по той же причине.
Canonical является главным спонсором здесь, и Oracle также инвестирует трудозатраты на эту технологию.
докер
Он имеет некоторые отличия, являясь самым крупным из них движком, который оборачивает приложения автономной файловой системой вместо базового «образа пользовательского пространства». Идея состоит в том, чтобы содержать приложение и базовое изображение, чтобы создать впечатление, что приложение представляет собой единый процесс внутри движка. Docker использовал технологию lxc в качестве базового для связи с ядром, но сегодня он использует свою собственную библиотеку libcontainer .
Файловая система является абстракцией Docker, в то время как lxc напрямую использует функции файловой системы. Сеть также является абстракцией, в то время как с помощью lxc вы можете легко настроить IP-адреса и конфигурации маршрутизации. Некоторые сайты, похожие на App Store, поддерживаются Microsoft, Amazon, Vmware, IBM и другими игроками.
Докер. INC. Является основным спонсором здесь. Vmware также инвестирует в эту технологию.
Связанные контейнерные технологии:
Это другие контейнерные технологии, которые есть в Linux: OpenVZ и Linux-VServer.
Источник
В чем разница между Docker, LXD и LXC [закрыт]
В чем разница между Docker, LXD и LXC. Предлагают ли они те же услуги или разные.
2 ответа
Нет, LXC, Docker и LXD, не совсем то же самое. Короче говоря:
Контейнеры LinuX (LXC) — это метод виртуализации на уровне операционной системы для запуска нескольких изолированных Linux-систем (контейнеров) на одном управляющем узле (хост LXC)
Docker
- от Docker, Inc
- контейнерная система, использующая контейнеры LXC
- , чтобы вы могли: Build, Ship, and Run Any App, Anywhere http: //www .docker.com
- от Canonical, Ltd
- a создание контейнерной системы использование контейнеров LXC
- , чтобы вы могли: run LXD on Ubuntu and spin up instances of RHEL, CentOS, SUSE, Debian, Ubuntu and just about any other Linux too, instantly, . http://www.zdnet.com/article/убунт-LXD-не-а-докер-замена-а-докер-повышение /
Докер против LXD
- Docker специализируется на развертывании приложений
- LXD специализируется на развертывании виртуальных машин (Linux)
Незначительное техническое примечание
- установка LXD включает в себя программу командной строки, совпадающую по имени lxc http://blog.scottlowe.org/2015/05/06/quick-intro-lxd/
Это изображение поможет вам понять основное различие между ними:
Все, что у них общего, состоит в том, что все эти 3 технологии связаны с контейнерами.
Контейнеры — это легкий механизм виртуализации, который не требует установки виртуальной машины при эмуляции физического оборудования. В Linux у них есть общие функции Kernel: cgroups , namespaces(ipc, network, user, pid, mount) . Они также пытаются создать более безопасные среды, создавая непривилегированные контейнеры и интегрируя их с такими функциями безопасности, как selinux . Эти технологии экспортируют API для лучшей интеграции с другими программными продуктами.
LXD и LXC
Эти два объединяют с тем же семейством , где:
- lxc : пользовательский интерфейс для функций локализации ядра Linux. Это тот парень, который управляет пространствами имен ядра, профилями Apparmor и SELinux, возможностями Chroots, Kernel и всеми другими материалами, связанными с ядрами.
- lxd : это гипервизор контейнера. Он состоит из демона (lxd), интерфейса командной строки (lxc) и плагина OpenStack. Этот парень был разработан, чтобы обеспечить большую гибкость и функции для lxc, в то время как он все еще использует его под капотом.
В принципе, пользовательское пространство автономной ОС создается с изолированной инфраструктурой. lxc более подробно опирается на функции ОС для сетей и хранения, чем Docker.
Вы создаете много виртуальных машин, у которых есть разделение пользователей и ядра, но они не являются полными виртуальными машинами, так как они не запускают разделенные ядра, и не являются паравиртуализированными по той же причине.
Canonical является основным спонсором здесь, и Oracle также инвестирует человеческие часы в эту технологию.
Докер
У этого есть некоторые отличия, являясь самым большим из них Engine, который обертывает Приложения с автономной файловой системой вместо базового образа «Userpace». Идея состоит в том, чтобы содержать приложение и базовое изображение, чтобы создать впечатление, что приложение является одним процессом внутри движка. Docker использовал технологию lxc как базовую для связи с ядром, но сегодня он использует собственную библиотеку, libcontainer ,
Файловая система является абстракцией для Docker, а lxc напрямую использует функции файловой системы. Сеть также является абстракцией, а с помощью lxc вы можете легче настроить IP-адреса и конфигурации маршрутизации. Некоторые сайты «Store Store» поддерживаются Microsoft, Amazon, Vmware, IBM и другими игроками.
Докер. INC. Является главным спонсором здесь. Vmware также инвестирует в эту технологию .
Связанная контейнерная технология:
Это другие контейнерные технологии, которые Linux имеют: OpenVZ и Linux-VServer
Источник
Docker vs LXD(LXC)
Хочу сделать ремарку, что я вообще в этом не специалист и разбирался со всем на ощупь.
Так уж случилось что пришлось столкнуться с контейнерами. Решил освоить для отделения мух от котлет разделения девелоперской машины и рабочего сервера для локальных проектов. Хотел настроить git и LSP на сервере, и выбор пал на текущие решения контейнеризации.
Когда-то использовал Docker для разворачивания отдельного приложения из образа и были некоторые проблемы с монтированием папок в него (может быть вообще не так нужно было делать), хотел сделать общую директорию для хоста и гостя, в итоге наткнулся на огромнейшее количество костылей для этого и остального.
Сейчас создал контейнер в LXD и мне это очень понравилось, всё стало буквально из коробки, для непривелигилированого контейнера просто добавил юзера в группу lxd.
Я понимаю что Docker более ориентирован на контейниризацию приложений, но всё же хотелось сравнить с контейниризацией ОС.
Поскольку Docker переехал на свои рельсы, я так понимаю, ради кроссплатформенности, то в чём плюсы и минусы Docker и LXD на данный момент. В интернете все нахваливают Docker, но я не пойму за что, ведь на мой дилетантский взгляд, LXD ничем не уступает.
UPD: Если туплю, то не сильно сердитесь. Пятница же!
Тёплое и мягкое.
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, то не следует использовать docker.
Тебе придётся поверить мне на слово. Учить азам сейчас не досуг.
Азам шизы? Ну, ладно. Как-нибудь обойдусь.
Иди лечись, друг мой. Всего хорошего, до свидания.
Докер раздувает системные требования (к оперативной памяти и кэшам, за счёт дублирования библиотек) и сильно усложняет flow обновления.
- Оригинальный подход Unix/Linux с динамической компоновкой: обновить дистрибутив штатным пакетным менеджером, иногда пересобрать прикладной софт.
- Подход со статической компоновкой, языкоспецифичными библиотеками и прочим новомодным пиннингом: обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости прикладного софта, пересобрать прикладной софт.
- Подход с Docker: обновить базовый образ, инвалидировать кэш сборщика, обновить дистрибутив штатным пакетным менеджером, бампнуть зависимости прикладного софта, пересобрать прикладной софт.
Но более важная проблема в том, что никто из докеролюбов не заморачивается даже тем, что я написал. Берётся первый попавшийся базовый образ, на коленке методом «херак-херак» пишется докерфайл, после чего про базовую систему в принципе забывается, и когда следующий раз она получит обновления — большой вопрос.
Тот же вопрос возникает, когда софт уже написан и новые ревизии софта выкатываются в общем-то весьма редко. Вот ты отдаёшь себе отчёт в том, что даже если твой софт не обновляется, докер-образ всё равно нужно регулярно пересобирать, чтобы подтянулись обновления базовой системы? Уверен, что нет. Да и процессы CI/CD в 95% случаев построены так, что это сделать затруднительно, т. к. образы кэшируются на всех уровнях по ID коммита.
С другой стороны, в принципе, если квалификация команды такова, что процессы построены на от5.1сь, то нет никакой разницы, построены они на докере или на чём-то другом. Просто подход докера очень сильно упрощает, облегчает и порой даже рекомендует делать неправильно.
Допустим, у тебя десять команд, два десятка проектов с кучкой сервисов в каждом и никаких проблем с бюджетом на железо. Каким нужно быть идиотом, чтобы не использовать универсальный способ деплоя для всего этого?
никто из докеролюбов не заморачивается даже тем, что я написал
Этим занимается служба эксплуатации (исключая прибитые зависимости, конечно). Далее всё в молоко.
Этим занимается служба эксплуатации (исключая прибитые зависимости, конечно).
«Для этого есть отряд специально обученных людей.» ©
Посмотрел одним глазком на Kubernetes, Ansible etc.
Я так понимаю что в современном IT искоренилось понятие программы как скомпилированого кода, а стало как набор декларативно развёрнутых контейнеров, которые «вещь в себе». При всём этом легче оперативы докупить чем ликвидировать весь этот зоопарк.
Docker это flatpack на стеройдах, а lxc почти виртуалка, не хватает ядра и загрузчика.
Стероидный Flatpak который носит ВСЁ с собой.
Сейчас создал контейнер в LXD и мне это очень понравилось, всё стало буквально из коробки, для непривелигилированого контейнера просто добавил юзера в группу lxd.
Ну да, для Докера группа ldx не играет роли. Там группа docker. Может дело в этом? Хи-хи.
Стероидный Flatpak который носит ВСЁ с собой.
Да, никто не запрещает запускать несколько копий докеризованного приложения. В докере необходимо держать все данные вне контейнера.
Допустим, у тебя десять команд, два десятка проектов с кучкой сервисов в каждом и никаких проблем с бюджетом на железо. Каким нужно быть идиотом, чтобы не использовать универсальный способ деплоя для всего этого?
Докер — это не способ деплоя. Это способ поставки.
Этим занимается служба эксплуатации
Источник
