Що Docker додає до інструментів lxc (інструментів LXC простору користувача)?


398

Якщо ви подивитеся на функції Докера, більшість з них вже надає LXC.

Отже, що додає Докер? Навіщо мені використовувати Docker над звичайним LXC?

Відповіді:


550

Із FAQ про Docker :

Docker не є заміною lxc. "lxc" відноситься до можливостей ядра Linux (конкретно просторів імен та груп управління), які дозволяють здійснювати процеси пісочниці один від одного та контролювати їх розподіл ресурсів.

Окрім цієї низькорівневої основи функцій ядра, Docker пропонує інструмент високого рівня з кількома потужними функціоналами:

  • Переносне розгортання на машинах.Docker визначає формат для поєднання програми та всіх її залежностей в єдиний об'єкт, який можна перенести на будь-яку машину з включеною докеркою та виконати там з гарантією, що середовище виконання, яке піддається дії програми, буде однаковим. Lxc реалізує процес пісочниці, що є важливою передумовою для розгортання портативних пристроїв, але цього лише для портативного розгортання недостатньо. Якщо ви надіслали мені копію вашої програми, встановленої у користувальницькій конфігурації lxc, вона майже напевно не працюватиме на моїй машині так, як це робиться на вашій, оскільки вона прив’язана до конкретної конфігурації вашої машини: мережа, зберігання, ведення журналів, дистрибутив, і т. д. Docker визначає абстракцію цих налаштувань для конкретних машин, щоб точно той самий контейнер докера міг працювати без змін - на багатьох різних машинах,

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

  • Автоматична збірка . Docker включає в себе інструмент для розробників для автоматичного збирання контейнера з їх вихідного коду з повним контролем залежностей від програми, побудови інструментів, упаковки тощо. Вони вільні у використанні make, maven, шеф-кухаря, маріонетки, солі, пакунків debian, rpms, джерела тарілки або будь-яка комбінація перерахованих вище, незалежно від конфігурації машин .

  • Версія. Докер включає в себе можливості, подібні до git, для відстеження послідовних версій контейнера, перевірки відмінностей між версіями, створення нових версій, відкочування тощо. Історія також включає, як контейнер збирався і ким, тож ви отримуєте повну простежуваність від виробничого сервера весь шлях до розробника вище. Docker також реалізує додаткові завантаження та завантаження, подібні до "git pull", тому нові версії контейнера можна переносити, лише надсилаючи diff.

  • Повторне використання компонента. Будь-який контейнер може бути використаний як "базове зображення" для створення більш спеціалізованих компонентів. Це можна зробити вручну або як частина автоматизованої збірки. Наприклад, ви можете підготувати ідеальне середовище python та використовувати його як основу для 10 різних застосувань. Ваша ідеальна настройка postgresql може бути використана для всіх ваших майбутніх проектів. І так далі.

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

  • Інструментальна екосистема. Docker визначає API для автоматизації та налаштування створення та розміщення контейнерів. Існує величезна кількість інструментів, що інтегруються з docker для розширення його можливостей. PaaS-подібне розгортання (Dokku, Deis, Flynn), багатовузлова оркестрація (maestro, сіль, mesos, openstack nova), панелі управління (docker-ui, openstack horizon, верф), управління конфігурацією (шеф-кухар, лялька), безперервна інтеграція (дженкіни, стридер, травіс) і т. д. Докер швидко утверджується як стандарт для контейнерних інструментів.

Я сподіваюся, що це допомагає!


3
Коли ви говорите, "будь-який контейнер може бути використаний як базове зображення", я припускаю, що ви маєте на увазі контейнер Docker, а не контейнер LXC, створений незалежно від Docker. Наскільки я можу сказати, ніхто не може створити контейнер Docker з нуля, він завжди повинен успадковуватися від іншого контейнера Docker (пов'язане питання: stackoverflow.com/questions/18274088/… ).
Flimm

18
Ви можете легко створити новий контейнер з будь-якого тарболу за допомогою "імпорту докера". Наприклад: "debootstrap raring ./rootfs; tar -C ./rootfs -c. | Docker import flimm / mybase".
Соломон Гайкс

3
це все-таки вірно зараз, коли Докер отримав liconcontainer (що це не заміна)?
Гарет Клаборн

3
@GaretClaborn так, оскільки libcontainer - це лише власна бібліотека для доступу до просторів імен та груп, все, що сказав Соломон, все ще стосується.
Джон Моралес

10
Контейнер Linux є результатом обмеження та ізоляції процесу за допомогою набору засобів Linux: chroot, cgroups та простору імен. LXC - це інструмент простору користувачів, який маніпулює цими об'єктами. libcontainer - це альтернатива LXC, яка маніпулює тими ж об'єктами. Docker використовує libcontainer за замовчуванням, але може використовувати LXC. Однак, Docker - це набагато більше, ніж шар сумісності поверх libcontainer / LXC; він додає додаткові функції, які перелічені інші відповіді.
користувач100464

71

Давайте подивимось на перелік технічних особливостей Docker та перевіримо, які з них надає LXC, а які - ні.

Особливості:

1) Ізоляція файлової системи : кожен контейнер процесу працює в абсолютно окремій кореневій файловій системі.

Забезпечується звичайним LXC.

2) Ізоляція ресурсів : системні ресурси, такі як процесор і пам'ять, можуть бути розподілені по-різному на кожен контейнер процесу, використовуючи cgroups.

Забезпечується звичайним LXC.

3) Мережева ізоляція : кожен контейнер процесу працює у власному просторі імен мережі з власним віртуальним інтерфейсом та IP-адресою.

Забезпечується звичайним LXC.

4) Copy-on-write : кореневі файлові системи створюються за допомогою функції "copy-on-write", що робить розгортання надзвичайно швидким, дешевим у пам'яті та дешевим на диску.

Це забезпечує AUFS, файлова система об'єднання, від якої залежить Докер. Ви можете налаштувати AUFS самостійно вручну за допомогою LXC, але Docker використовує його як стандарт.

5) Ведення журналу : стандартні потоки (stdout / stderr / stdin) кожного технологічного контейнера збираються та реєструються для реального часу або пакетного пошуку.

Докер це забезпечує.

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

"Шаблон або налаштування вручну" - це посилання на LXC, де вам потрібно буде дізнатися про обидва ці речі. Docker дозволяє обробляти контейнери так, як ви звикли обробляти віртуальні машини, не дізнаючись про конфігурацію LXC.

7) Інтерактивна оболонка : докер може виділити псевдо-tty та приєднати до стандартного вводу будь-якого контейнера, наприклад, для запуску інтерактивної оболонки, що викидається.

LXC це вже забезпечує.


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


35
ІМХО, ця відповідь пропускає суть. Docker не "надає" ці функції; це просто робить їх тривіально простими у використанні. Якщо ми хочемо бути невиразними, ми можемо сказати, що LXC не забезпечує ізоляцію: простори імен надають це, а LXC - лише інструмент користувальницької сировини, щоб зробити їх простішим у використанні, ніж основним unshareінструментом (або безпосередньо системою clone()syscall). Так само Docker робить такі речі простішими у використанні (та пропонує багато інших функцій на столі, наприклад, можливість натискання / перетягування зображень). Мій 2с.
jpetazzo

6
@jpetazzo: LXC насправді досить простий, як Docker робить це легше (окрім додавання інших функцій, таких як натискання та перетягування зображень)?
Flimm

31
@Flimm: Мені подобається порівняння у випуску 16 журналу адміністратора , стор. 34: Докер поєднує LXC разом з деякими іншими підтримуючими технологіями та обертає його у простий у користуванні інтерфейс командного рядка. Використання контейнерів трохи схожий на спробу використовувати Git тільки з командами , як update-indexі read-treeбез звичних інструментів , таких як add, commitі merge. Docker забезпечує цей шар "порцеляни" над "сантехнікою" LXC, що дозволяє вам працювати з концепціями вищого рівня і менше турбуватися про деталі низького рівня.
0xC0000022L

4
Я запустив орієнтири UnixBench всередині докерного контейнера та контейнера LXC, запускаючи ту саму ОС, і LXC досяг найкращого результату. Будучи докером на базі LXC, я дуже спантеличений своїми результатами.
gextra

7
Мені здається, що більш повільна продуктивність Докера була пов'язана з дисковим входом / виходом, тому, можливо, викликана прийняттям AUFS.
gextra

16

Вищезгадані публікації та відповіді швидко набувають дату, оскільки розвиток LXD продовжує вдосконалювати LXC . Так, я знаю, що Докер теж не стояв на місці.

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

Тепер LXD-програма REST для LXC дозволяє як локальне, так і віддалене створення / розгортання / управління контейнерами LXC, використовуючи дуже простий синтаксис команд.

Основними особливостями LXD є:

  • Забезпечено дизайном (непривілейовані контейнери, обмеження ресурсів та багато іншого)
  • Масштабованість (від контейнерів на вашому ноутбуці до тисяч обчислювальних вузлів)
  • Інтуїтивно зрозумілий (простий, зрозумілий API та чіткий досвід командного рядка)
  • На основі зображень (більше немає шаблонів розповсюдження, лише хороші, надійні зображення) Жива міграція

Існує NCLXD плагін тепер OpenStack дозволяючи OpenStack використовувати LXD для розгортання / управління LXC контейнерів як віртуальні машини в OpenStack замість використання KVM, VMware і т.д.

Однак NCLXD також дозволяє гібридну хмару поєднання традиційних HW VM та LXC VM.

У плагін 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 року з'явилися додаткові цікаві функції, такі як підтримка блокових пристроїв, підтримка живої міграції .


4

Докери використовують зображення, побудовані в шари. Це додає багато що стосується портативності, спільного використання, версій та інших функцій. Ці зображення дуже легко переносити або переносити, і оскільки вони знаходяться в шарах, зміни в наступних версіях додаються у вигляді шарів над попередніми шарами. Отже, переносячи багато разів, вам не потрібно переносити базові шари. Докери мають контейнери, в яких запущені ці зображення із середовищем виконання, вони додають зміни як нові шари, забезпечуючи простий контроль версій.

Крім цього Docker Hub - це гарний реєстр з тисячами публічних зображень, де ви можете знайти зображення, на яких встановлена ​​ОС та інші програмні засоби. Отже, ви можете отримати досить непоганий початок вашої заявки.


Коли ви говорите "побудований в шари" - що це означає - (A) Копія базових шарів, адаптованих та привласнених до "НОВОГО" шару. Отже, базовий шар відключається від наступного? (B) Базовий (и) шар (и) є / включаються в шар "НОВО" та також пов'язані між собою. Отже, зміни базового шару автоматично відображаються на шарі "НОВО". Вибачте, якщо шукане роз'яснення занадто наївне. :( Капіль
Капіль

Образи докера будуються шарами. Якщо викласти деталізовані терміни, всі зміни до точки, коли шар здійснюється, є шарами зображення, зробленими до цієї точки. Будь-які зміни, внесені після цього, додаються до наступного та вище шарів. Отже, новий шар пов'язаний з базовим шаром. Я не думаю, що той самий новий шар може бути доданий до іншого базового шару з додатковими змінами. Однак якщо декілька сутностей хочуть підтримувати узгодженість і мають однакові базові шари, то для досягнення одного і того ж стану цим особам потрібно надати лише нові шари.
дів

Однак я не поінформований про поточні події в docker, і можуть бути зміни в реалізації зображення докера, які не розглядаються в коментарі вище.
дів

Якщо бути більш конкретним, шари ідентифікуються підписом (SHA-щось, я вважаю), що означає, що якщо ви змінюєте шар, це буде інший шар. @Kapil: Це означає, що, хоча його поведінка дещо наближається до вашого варіанту (B), ви насправді не можете внести зміни до базового шару. (або будь-який шар з цього питання) Зображення складається з переліку шарів, кожен із яких застосовується в порядку; шари можна очистити (і я думаю, що вони автоматично очищуються самим докером), коли вони більше не потрібні; тобто коли всі посилання на зображення були видалені.
codermonkeyfuel

@Kapil: Чесно кажучи, ваше питання, мабуть, найкраще спрацює як нове запитання, а не як коментар до цього, оскільки це корисно для людей, щоб мати можливість шукати самостійно. Якщо ви хочете задати це як нове запитання, я теж відповім.
codermonkeyfuel

0

Збираючись зберегти цю пітфію, про це вже запитували і відповіли вище .

Але я б відступив назад і відповів на це дещо інакше, сам докерний двигун додає оркестрацію як одну з його додаткових можливостей, і це руйнівна частина. Після запуску програми як комбінації контейнерів, що працюють "десь" у кількох двигунах контейнерів, це стає дуже цікавим. Міцність, горизонтальне масштабування, повна абстракція від базового обладнання, я міг би продовжувати і продовжувати ...

Це не тільки Docker, який дає вам це, насправді стандарт фактичної оркестровки контейнерів - це Kubernetes, який має багато смаків, Docker, але також OpenShift, SuSe, Azure, AWS ...

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.