Что Docker добавляет в lxc-tools (инструменты LXC пользовательского пространства)?

398

Если вы посмотрите на функции Docker, большинство из них уже предоставлены LXC.

Так что же добавляет Docker? Зачем мне использовать Docker поверх простого LXC?

docker lxc Флимм
источник

Ответы:

550

Из Docker FAQ :

Докер не является заменой для lxc. «lxc» относится к возможностям ядра Linux (в частности, к пространствам имен и контрольным группам), которые разрешают процессы песочницы друг от друга и управляют их распределением ресурсов.

В дополнение к этому низкоуровневому фундаменту функций ядра, Docker предлагает инструмент высокого уровня с несколькими мощными функциями:

  • Переносимое размещение на разных машинах.Docker определяет формат для объединения приложения и всех его зависимостей в один объект, который можно перенести на любой компьютер с поддержкой Docker и выполнить там с гарантией того, что среда выполнения, представленная приложению, будет одинаковой. Lxc реализует изолированную программную среду процессов, которая является важной предпосылкой для переносимого развертывания, но одного этого недостаточно для переносимого развертывания. Если вы отправите мне копию вашего приложения, установленного в пользовательской конфигурации lxc, оно почти наверняка не будет работать на моем компьютере так же, как на вашем, потому что оно привязано к конкретной конфигурации вашего компьютера: сети, хранилищу, журналам, дистрибутиву, и т.д. Docker определяет абстракцию для этих машинно-специфических настроек, чтобы один и тот же Docker-контейнер мог работать - без изменений - на многих разных машинах,

  • Применение ориентированное. Docker оптимизирован для развертывания приложений , в отличие от машин. Это отражено в его API, пользовательском интерфейсе, философии дизайна и документации. Напротив, вспомогательные сценарии lxc ориентированы на контейнеры как на легковесные машины - в основном серверы, которые загружаются быстрее и требуют меньше оперативной памяти. Мы думаем, что контейнеры - это больше, чем просто.

  • Автоматическая сборка . Docker включает в себя инструмент для разработчиков, позволяющий автоматически собирать контейнер из их исходного кода с полным контролем над зависимостями приложений, инструментами сборки, упаковкой и т. Д. Они могут свободно использовать пакеты make, maven, chef, puppet, salt, debian, rpms, source тарболы или любую комбинацию вышеперечисленного, независимо от конфигурации машин .

  • Versioning. Docker включает в себя git-подобные возможности для отслеживания последовательных версий контейнера, проверки различий между версиями, фиксации новых версий, отката и т. Д. История также включает в себя то, как и кем был собран контейнер, так что вы получаете полную отслеживаемость с рабочего сервера. вплоть до разработчика. Docker также реализует инкрементную загрузку и загрузку, аналогично «git pull», поэтому новые версии контейнера могут передаваться только путем отправки различий.

  • Компонент повторного использования. Любой контейнер можно использовать в качестве «базового изображения» для создания более специализированных компонентов. Это можно сделать вручную или как часть автоматизированной сборки. Например, вы можете подготовить идеальную среду Python и использовать ее в качестве основы для 10 различных приложений. Ваша идеальная настройка postgresql может быть повторно использована для всех ваших будущих проектов. И так далее.

  • Совместное использование. Docker имеет доступ к общедоступному реестру ( https://registry.hub.docker.com/ ), куда тысячи людей загрузили полезные контейнеры: от redis, couchdb, postgres до irc-bouncers, на серверы приложений rails, от hadoop для создания базовых образов для различные дистрибутивы. Реестр также включает официальную «стандартную библиотеку» полезных контейнеров, поддерживаемую командой докеров. Сам реестр имеет открытый исходный код, поэтому любой может развернуть свой собственный реестр для хранения и передачи частных контейнеров, например, для внутренних развертываний серверов.

  • Инструментальная экосистема. Docker определяет API для автоматизации и настройки создания и развертывания контейнеров. Существует огромное количество инструментов, интегрируемых с докером для расширения его возможностей. PaaS-подобное развертывание (Dokku, Deis, Flynn), многоузловая оркестровка (maestro, salt, mesos, openstack nova), панели управления (docker-ui, openstack horizon, верфь), управление конфигурациями (chef, puppet), непрерывная интеграция (Дженкинс, Страйдер, Трэвис) и т. д. Docker быстро утвердился в качестве стандарта для инструментов на основе контейнеров.

Надеюсь, это поможет!

Соломон Хайкс
источник
3
Когда вы говорите «любой контейнер может использоваться в качестве базового образа», я предполагаю, что вы имеете в виду контейнер Docker, а не контейнер LXC, созданный независимо от Docker. Насколько я могу судить, нельзя создать контейнер Docker с нуля, он всегда должен наследоваться от другого контейнера Docker (связанный вопрос: stackoverflow.com/questions/18274088/… ).
Flimm
18
Вы можете легко создать новый контейнер из любого архива с помощью «импорта докеров». Например: "debootstrap raring ./rootfs; tar -C ./rootfs -c. | Docker import flimm / mybase".
Соломон Хайкс
3
верно ли это сейчас, когда Докер получил libcontainer (что не замена)?
Гарет Клаборн
3
@GaretClaborn да, поскольку libcontainer - это просто их собственная библиотека для доступа к пространствам имен и группам, все, что сказал Соломон, все еще применимо.
Джон Моралес
10
Контейнер Linux является результатом ограничения и изоляции процесса с использованием набора средств Linux: chroot, cgroups и пространств имен. LXC - инструмент пользовательского пространства, который управляет этими средствами. libcontainer - это альтернатива LXC, которая манипулирует теми же средствами. Docker использует libcontainer по умолчанию, но вместо этого может использовать LXC. Тем не менее, Docker (намного) больше, чем уровень совместимости поверх libcontainer / LXC; он добавляет дополнительные функции, перечисленные в других ответах.
user100464
71

Давайте посмотрим на список технических возможностей Docker и проверим, какие из них предоставляются LXC, а какие нет.

Особенности:

1) Изоляция файловой системы : каждый контейнер процессов работает в совершенно отдельной корневой файловой системе.

Предоставляется простой LXC.

2) Изоляция ресурсов : системные ресурсы, такие как процессор и память, могут быть распределены по-разному для каждого контейнера процесса, используя cgroups.

Предоставляется простой LXC.

3) Изоляция сети : каждый контейнер процессов работает в своем собственном пространстве имен сети, с виртуальным интерфейсом и собственным IP-адресом.

Предоставляется простой LXC.

4) Копирование при записи : корневые файловые системы создаются с использованием копирования при записи, что делает развертывание чрезвычайно быстрым, дешевым в памяти и дешевым диском.

Это обеспечивается AUFS, объединенной файловой системой, от которой зависит Docker. Вы можете вручную настроить AUFS с помощью LXC, но Docker использует его в качестве стандарта.

5) Ведение журнала : стандартные потоки (stdout / stderr / stdin) каждого контейнера процессов собираются и регистрируются для поиска в режиме реального времени или в пакетном режиме.

Докер обеспечивает это.

6) Управление изменениями: изменения в файловой системе контейнера могут быть зафиксированы в новом образе и использованы повторно для создания большего количества контейнеров. Нет шаблонов или ручная настройка не требуется.

«Шаблонная или ручная настройка» - это ссылка на LXC, где вам необходимо узнать обо всех этих вещах. Docker позволяет вам обращаться с контейнерами так, как вы привыкли обращаться с виртуальными машинами, не изучая конфигурацию LXC.

7) Интерактивная оболочка : docker может выделить псевдо-tty и прикрепить к стандартному вводу любого контейнера, например, для запуска одноразовой интерактивной оболочки.

LXC уже обеспечивает это.

Я только начал узнавать о LXC и Docker, так что я буду рад любым исправлениям или лучшим ответам.

Флимм
источник
35
ИМХО, этот ответ упускает из виду. Докер не "предоставляет" эти функции; это просто делает их тривиально простыми в использовании. Если мы хотим быть придирчивыми, мы можем сказать, что LXC не обеспечивает изоляцию: пространства имен обеспечивают ее, а LXC - это просто инструмент пользовательского пользовательского интерфейса, облегчающий их использование, чем с помощью основного unshareинструмента (или непосредственно clone()системного вызова). Аналогичным образом, Docker делает эти вещи более простыми в использовании (и предоставляет гораздо больше функций на столе, например, возможность выдвигать / извлекать изображения). Мой 2с.
jpetazzo
6
@jpetazzo: LXC на самом деле довольно прост, как Docker делает это проще (помимо добавления других функций, таких как перемещение и извлечение изображений)?
Flimm
31
@Flimm: мне нравится сравнение в выпуске 16 журнала Admin , с. 34: Docker связывает LXC с некоторыми другими поддерживающими технологиями и оборачивает его в простой в использовании интерфейс командной строки. Использование контейнеров немного походит на попытку использовать Git только с командами , как update-indexи read-treeбез привычных инструментов , таких как add, commitи merge. Docker предоставляет этот слой «фарфора» поверх «сантехники» LXC, что позволяет вам работать с концепциями более высокого уровня и меньше беспокоиться о деталях низкого уровня.
0xC0000022L
4
Я запустил тесты UnixBench в док-контейнере и контейнере LXC, работающих под управлением одной и той же ОС, и LXC показал отличные результаты. Будучи докером на основе LXC, я очень озадачен своими результатами.
Gextra
7
Мне кажется, что более низкая производительность Docker была связана с дисковым вводом / выводом, поэтому, возможно, это вызвано принятием AUFS.
Gextra
16

Приведенные выше посты и ответы быстро устаревают, поскольку развитие LXD продолжает улучшать LXC . Да, я знаю, что Докер тоже не стоял на месте.

LXD теперь реализует репозиторий для изображений контейнеров LXC, из которых пользователь может выдвигать / извлекать, чтобы внести свой вклад или использовать повторно.

REST api от LXD для LXC теперь позволяет как локально, так и удаленно создавать / развертывать / управлять контейнерами LXC, используя очень простой командный синтаксис.

Ключевые особенности LXD:

  • Безопасный дизайн (непривилегированные контейнеры, ограничения ресурсов и многое другое)
  • Масштабируемость (от контейнеров на вашем ноутбуке до тысячи вычислительных узлов)
  • Интуитивно понятный (простой, понятный API и четкий интерфейс командной строки)
  • На основе изображений (больше шаблонов распространения, только хорошие, надежные изображения) Живая миграция

Существует NCLXD плагин теперь OpenStack позволяя OpenStack использовать LXD для развертывания / управления LXC контейнеров как виртуальные машины в OpenStack вместо использования KVM, VMware и т.д.

Тем не менее, NCLXD также позволяет использовать гибридное облако из комбинации традиционных виртуальных машин HW и виртуальных машин LXC.

Плагин OpenStack nclxd содержит список поддерживаемых функций:

stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support

Ко времени выхода Ubuntu 16.04 в апреле 2016 года появятся дополнительные интересные функции, такие как поддержка блочных устройств, поддержка динамической миграции .

bmullan
источник
4

Докеры используют изображения, которые встроены в слои. Это добавляет много с точки зрения переносимости, обмена, управления версиями и других функций. Эти изображения очень легко переносить или передавать, и, поскольку они находятся в слоях, изменения в последующих версиях добавляются в виде слоев поверх предыдущих слоев. Таким образом, при переносе много раз вам не нужно переносить базовые слои. У докеров есть контейнеры, которые запускают эти образы со встроенной средой исполнения, они добавляют изменения в виде новых слоев, обеспечивая легкий контроль версий.

Кроме того, Docker Hub - это хороший реестр с тысячами общедоступных образов, где вы можете найти образы с установленной ОС и другим программным обеспечением. Таким образом, вы можете получить довольно хороший старт для вашего приложения.

ДИВ
источник
Когда вы говорите «встроенные слои» - что это значит - (A) Копия базовых слоев, адаптированная и зафиксированная для «НОВОГО» слоя. Итак, базовый слой отключен от следующего? (B) Базовый (ые) слой (и) включен (ы) в «НОВЫЙ» слой и также связан. Таким образом, изменения в базовом слое автоматически отражаются в «новом» слое. Извините, если запрошенное разъяснение слишком наивно. :( Капил
Капил
Изображения Docker встроены в слои. Если говорить более детально, все изменения вплоть до момента, когда слой зафиксирован, присутствуют в слоях изображения, созданного до этой точки. Любые изменения, сделанные после этого, добавляются к следующим и выше слоям. Итак, новый слой связан с базовым слоем. Я не думаю, что тот же новый слой может быть добавлен в другой базовый слой с дополнительными изменениями. Однако, если несколько объектов хотят поддерживать согласованность и иметь одинаковые базовые уровни, то для достижения одного и того же состояния этим объектам необходимо предоставить только новые слои.
Div
Тем не менее, я не в курсе текущих событий в Docker, и могут быть изменения в реализации образа Docker, которые не описаны в комментарии выше.
Div
Чтобы быть более точным, слои идентифицируются подписью (я считаю, что это что-то SHA), что означает, что если вы меняете слой, это другой слой. @Kapil: Это означает, что, хотя его поведение несколько ближе к вашему варианту (B), вы на самом деле не можете вносить изменения в базовый слой. (или любой слой, если на то пошло) Изображение строится из списка слоев, каждый из которых применяется по порядку; слои могут быть очищены (и я думаю, что они автоматически очищаются самим докером), когда они больше не нужны; т.е. когда все ссылочные изображения были удалены.
codermonkeyfuel
@Kapil: Честно говоря, ваш вопрос, вероятно, лучше всего подойдет как новый вопрос, а не как комментарий к нему, поскольку людям полезно иметь возможность искать его самостоятельно. Если вы хотите задать его как новый вопрос, я отвечу и там.
codermonkeyfuel
0

Собираюсь держать эту кучку, об этом уже спрашивали и отвечали выше .

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

Это дает не только Docker, на самом деле стандартом де-факто оркестровки контейнеров является Kubernetes, который представлен во множестве разновидностей Docker, но также OpenShift, SuSe, Azure, AWS ...

Тогда под K8S есть альтернативные контейнерные двигатели; наиболее интересными являются Docker и CRIO - недавно построенные, без демонов, предназначенные как контейнерный движок специально для Kubernetes, но незрелые. Это соревнование между ними, которое, я думаю, станет настоящим долгосрочным выбором для контейнерного двигателя.

Уилл Ротвелл
источник