Питання Як Docker відрізняється від віртуальної машини?


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

Чому розгортання програмного забезпечення до зображення докерів (якщо це правильний термін) є простішим, ніж просто розгортання до послідовного виробничого середовища?


2921
2018-04-16 21:19


походження


Аналіз продуктивності Docker vs KVM: bodenr.blogspot.com/2014/05/... - HDave
Якщо ви шукаєте різницю між їх зображеннями - stackoverflow.com/questions/29096967/... - devesh-ahuja
Докер не є віртуальною машиною - це інструмент керування конфігурацією. - aaa90210
@JagatveerSingh Thought я хотів би згадати, що це посилання на це ж питання. - Dan Nissenbaum
Стічні переповнення - це сайт для програмного забезпечення та питань розробки. Це питання, здається, не пов'язаний з темою, оскільки мова йде не про програмування чи розробку. Побачити Які теми можна запитати тут у довідковому центрі. Можливо Супер Користувач або Unix і Linux Stack Exchange було б краще запитати. - jww


Відповіді:


Докер спочатку використовувався Контейнери LinuX (LXC), але пізніше перейшов на runC (раніше відома як libcontainer), який працює у тій самій операційній системі, що і її хост. Це дозволяє йому поділитися багатьма ресурсами операційної системи хосту. Крім того, він використовує багатошарову файлову систему (AuFS) та керує мережею.

AuFS - це шаброва файлова система, тому ви можете мати частину, що читається, та частину запису, які об'єднані разом. Можна мати спільні частини операційної системи як читану (і поділитись між усіма вашими контейнерами), а потім надавати кожному контейнері власну монтуру для написання.

Отже, скажімо, у вас є зображення контейнера 1 Гб; якщо ви хочете використовувати повний віртуальний мультимедійний каталог, вам потрібно буде мати 1 ГБ разів x кількість віртуальних машин, які ви хочете. За допомогою Docker та AuFS ви можете поділити основну частину 1 ГБ між усіма контейнерами, і якщо у вас є 1000 контейнерів, у вас може залишитися лише трохи більше 1 Гб простору для контейнерних ОС (якщо всі вони використовують той самий образ ОС) .

Повна віртуалізована система отримує власний набір ресурсів, що виділяються на нього, і робить мінімальний обмін. Ви отримуєте більше ізоляції, але це набагато важче (потрібно більше ресурсів). З Docker ви отримуєте менше ізоляції, але контейнери легкі (потрібні менше ресурсів). Таким чином, ви можете легко запускати тисячі контейнерів на хості, і це навіть не блимає. Спробуйте це зробити з Xen, і якщо у вас немає дійсно великого хоста, я не думаю, що це можливо.

Повна віртуалізована система зазвичай займає декілька хвилин, а контейнери Docker / LXC / runC вимагають секунд, а часто навіть менше секунди.

Є плюси і мінуси для кожного виду віртуалізованої системи. Якщо ви хочете повної ізоляції з гарантованими ресурсами, то повна віртуальна машина - це шлях. Якщо ви просто хочете ізолювати процеси один від одного і хочете запустити тонну з них на розмірі хоста, то Docker / LXC / runC, здається, є способом іти.

Для отримання додаткової інформації, перевірте цей набір повідомлень в блозі які допомагають пояснити, як LXC працює.

Чому розгортання програмного забезпечення до зображення докерів (якщо це правильний термін) є простішим, ніж просто розгортання до послідовного виробничого середовища?

Розгортання послідовного виробничого середовища простіше сказати, ніж зробити. Навіть якщо ви використовуєте такі інструменти, як Шеф-кухар і Кукольник, завжди є оновлення ОС та інші речі, які змінюються між хостами та середовищами.

Докер дає вам змогу знімати ОС на загальному зображенні та полегшує його розміщення на інших хостах Docker. Місцево, dev, qa, prod тощо.: Все та ж зображення. Звичайно, ви можете зробити це за допомогою інших інструментів, але не так легко і швидко.

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

Від коментарів ...

Цікаво! Я вважаю, що я все ще заплутався під поняттям "знімок ОС". Як це робити без добре, створюючи образ ОС?

Ну, давайте подивимося, чи зможу я пояснити. Ви почнете з базового зображення, а потім внесете зміни та здійсните ці зміни за допомогою docker, і він створить зображення. Це зображення містить лише відмінності від бази. Якщо ви хочете запустити своє зображення, вам також потрібна база, і вона розміщує ваше зображення на верхній частині бази, використовуючи багатошарову файлову систему: як згадувалося вище, Docker використовує AUFS. AUFS об'єднує різні шари, і ви отримуєте те, що хочете; вам просто потрібно запустити його. Ви можете продовжувати додавати більше і більше зображень (шарів), і він буде продовжувати зберігати лише розбіжності. Оскільки Докер, як правило, збирається на вершині готових зображень з реєстр, вам рідко доводиться "робити знімок" всю операційну систему самостійно.


2817
2018-04-16 22:35



Кен, у деяких місцях ви зближуєте ОС з ядром. Всі контейнери на хості працюють під одним ядром, але решту файлів ОС може бути унікальним для кожного контейнера. - Andy
Цікаво! Я вважаю, що я все ще заплутався під поняттям "знімок ОС". Як це робити без добре, створюючи образ ОС? - zslayton
@ murtaza52 вони додають підтримку для різних файловых систем, тому Aufs відходить не повинно бути проблемою. Не впевнений, коли буде додано 32-бітну підтримку, не думайте, що там був сильний попит, тому він був низьким у списку пріоритетів, але я міг би помилятися. - Ken Cochrane
@Міке: ... який безсумнівно був натхненний В'язниці FreeBSD  HISTORY The jail utility appeared in FreeBSD 4.0. - Stefan Paletta
Для тих, хто цікавиться тим, що коментар до @ Майка, ми відповімо на це, оскільки він, як видається, був вилучений, це: <Одне справа відсутня - це посилання на те, що контейнери Linux є клоном справжнього джерела натхнення : Контейнери Solaris. Шлях назад у 2004 році ... Це революційна концепція та чудовий, чудовий спосіб зробити прийнятні, розміщені віртуальні машини, які справді є ефективними. Джойнт був першим, про кого я знаю ...> - Jeffrey 'jf' Lim


Хороші відповіді. Щоб отримати зображене зображення контейнера та віртуальної машини, перегляньте його нижче.

enter image description here

Джерело: https://www.docker.com/what-container#/package_software


342
2017-10-14 18:02



<strike> Наскільки я розумію, над "докерним движком" повинен бути загальний ядро ​​Linux. Потім існують навіть загальні розділи / бек. Спочатку після цього з'являються бункери / бібліотеки та додатки, специфічні для кожного контейнера. Будь ласка, виправте мене, якщо я помиляюся. </ Strike> Я помилявся. Докерські зображення поділяють ядро ​​на хост, див superuser.com/questions/889472/.... Проте, щоб проілюструвати об'єднану файлову систему контейнерів, може бути загальний шар libs / bins безпосередньо над докерним движком. - Betamos
У мене виникла проблема з наведеною вище картинкою, оскільки Hypervisor може бути встановлений на голій метал / інфраструктуру, але Docket не може (поки що) - reza
@reza, я погоджуюся, гіпервізор може бути встановлений на Bare metal, але справа в тому, що Docker рекомендується для контейнерування додатків і як обмежити або уникнути віртуалізації, який не потрібний / застосовний для деяких сценаріїв. Кен Кокран пояснює це докладніше stackoverflow.com/a/16048358/2478933 - manu97
Це не пояснює, що таке Докер Двигун. Дуже абстрактні картинки. - kyb
У контейнері та ядрі немає шару "Docker Engine", контейнер - це лише процес із спеціальними налаштуваннями в ядрі (простори імен, групові групи тощо). - Paweł Prażak


Можливо, було б корисно зрозуміти, як віртуалізація та контейнери працюють на низькому рівні. Це очистить багато речей.

Примітка. Я трохи спрощую описати нижче. Див. Посилання для отримання додаткової інформації.

Як працює віртуалізація на низькому рівні?

У цьому випадку менеджер VM бере на себе процесорний дзвінок 0 (або "кореневий режим" у нових процесорах) і перехоплює всі привілейовані дзвінки, створені гостовою ОС, для створення ілюзії, що гостьова ОС має власне обладнання. Цікавий факт: до 1998 р. Було неможливо досягти цього в архітектурі x86, оскільки не було можливості зробити такий перехват. Люди в VMWare були першими хто мав ідею переписати виконувані байти в пам'ять для привілейованих дзвінків гостьової ОС, щоб досягти цього.

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

Як контейнери працюють на низькому рівні?

Навколо 2006 р, люди, включаючи деяких співробітників компанії Google, запровадили нову функцію рівня ядра під назвою простір імен (однак ідея довго раніше існував у FreeBSD) Однією з функцій ОС є можливість спільного використання глобальних ресурсів, таких як мережа та диск, до процесів. Що робити, якщо ці глобальні ресурси були загорнуті в просторах імен так, щоб вони були видимими тільки для тих процесів, які працюють в одному іменному просторі? Скажімо, ви можете отримати частину диска і помістити це в просторі імен X, а потім процеси, що виконуються в просторі імен, не можуть бачити або отримати доступ до нього. Аналогічно, процеси в області імен не можуть отримати доступ до нічого в пам'яті, що виділяється на простір імен Y. Звичайно, процеси в X не можуть бачити або обговорювати процеси в області імен Y. Це забезпечує вид віртуалізації та ізоляції для глобальних ресурсів. Ось як працює docker: кожен контейнер працює у власному просторі імен, але використовує саме цей той же ядро, як і всі інші контейнери. Ізоляція відбувається тому, що ядро ​​знає про простір імен, який був призначений для процесу, і під час викликів API він гарантує, що процес може мати доступ лише до ресурсів у власному просторі.

Обмеження контейнерів і віртуальних машин тепер повинні бути очевидними: не можна запускати абсолютно іншу ОС в контейнерах, як у віртуальних машинах. Однак ти може запускати різні дистрибутиви Linux, оскільки вони мають однакове ядро. Рівень ізоляції не настільки сильний, як у VM. Фактично, існував спосіб для контейнера "гостьовий", щоб прийняти хост на ранніх реалізаціях. Також ви можете бачити, що при завантаженні нового контейнера вся нова копія ОС не починається, як це відбувається в VM. Всі контейнери поділитися одним ядром. Саме тому контейнери легкі. Крім того, на відміну від VM, вам не потрібно попередньо виділяти значну кількість пам'яті на контейнери, оскільки ми не використовуємо нову копію ОС. Це дає змогу запускати тисячі контейнерів на одній ОС під час їх ізольованого зберігання, що може бути неможливим, якщо ми використовуємо окрему копію ОС у власній віртуальній машині.


298
2018-01-13 01:49



Вау, дякую за чудове пояснення (і історичні факти) на низькому рівні. Я шукав це, і не знайдено вище. Що ти маєш на увазі "ви можете запускати різні дистрибутиви Linux, оскільки вони мають однакове ядро".? Ви кажете, що контейнер для гостя повинен мати точно таку ж версію ядра Linux або що це не має значення? Якщо це не має значення, що, якщо я викликаю команду ОС у гостя, але підтримується лише в ядрі гостя. Або, наприклад, помилка виправлена ​​в ядрі гостя, але не в ядрі хоста. Всі гості виявляли помилку, правильно? Хоча гості були виправлені. - Jeach
@Jeach: контейнери не мають власного ядра, вони діляться / використовують один з хостів. Таким чином, ви не можете запускати контейнери, для яких потрібні різні ядра, на одній машині / VM. - user276648
Питання: Ви пишете, що деякі співробітники Google були задіяні в функціях ядра в іменах приблизно в 1996 році, але Google не була заснована до 1998 року. Ви мали на увазі "людей, які пізніше стали б працювати в Google"? - Martin Gjaldbaek
@martin - дякую за те, що помітив, що цей рік був 2006 р. Крім того, слід зазначити, що в Linux з 2002 р. існують різні типи просторів імен, але це була робота в 2006 р., яка заклала основу для контейнеризації. Я оновив відповідь з посиланням. - ShitalShah
+1 Це повинно бути відмітною відповіддю, тоді як інші відповіді дають певне уточнення, лише пояснення знизу вгору до низького рівня дозволять з'ясувати, як працює ця технологія, "процеси, згруповані у власному просторі імен = контейнер". Дуже дякую, я зараз це отримую. - Tino Mclaren


Мені подобається відповідь Кен Кокран.

Але я хочу додати додаткову точку зору, не детально описану тут. На мій погляд, Докер відрізняється також у всьому процесі. На відміну від віртуальних машин, Docker не (тільки) про оптимальний обмін ресурсами обладнання, крім того, вона забезпечує "систему" для застосування в пакунку (бажано, але не обов'язково, як набір мікросервісів).

Для мене це вписується в розрив між інструментами, орієнтованими на розробників, такими як rpm, debian пакунки, maven, npm + git з одного боку та інструменти Ops, як Puppet, VMWare, Xen ви називаєте це ...

Чому розгортання програмного забезпечення до зображення докерів (якщо це правильний термін) є простішим, ніж просто розгортання до послідовного виробничого середовища?

Ваше запитання передбачає послідовне виробниче середовище. Але як зберегти його послідовність?  Розглянемо деяку кількість (> 10) серверів та програм, етапи в трубопроводі. Щоб зберегти це в синхронізації, ви почнете використовувати щось на зразок Puppet, Chef або власних сценаріїв надання, неопублікованих правил та / або партії документації. У теорії сервери можуть працювати на невизначений термін, а також залишатися повністю сумісними та оновленими. Практика не може повністю керувати конфігурацією сервера, тому існує значний простір для дрейфу конфігурації та несподіваних змін на робочих серверах.

Отже, існує відомий шаблон, щоб уникнути цього, так званого Необмежений сервер. Але незмінний шаблон сервера не любив. Переважно через обмеження VM він використовувався перед Docker. Робота з кількома великими зображеннями в гігабайтах, переміщення цих великих зображень навколо, просто для зміни деяких полів у додатку, була дуже трудомісткою. Зрозуміло ...

За допомогою екосистеми Docker вам ніколи не доведеться пересуватися по гігабайтах за "невеликими змінами" (Thanks aufs і Registry), і вам не потрібно турбуватися про втрату продуктивності за допомогою програм упакування в контейнері Docker під час виконання. Вам не потрібно турбуватися про версії цього зображення. І, нарешті, ви навіть зможете відтворити складні виробничі середовища навіть на вашому ноутбуці linux (не дзвоніть, якщо він не працює у вашому випадку;))

І, звичайно, ви можете запустити докер-контейнери у віртуальних машинах (це гарна ідея). Зменшіть резервування сервера на рівні VM. Все перераховане вище може бути кероване Docker.

П.С. Тим часом Docker використовує власну реалізацію "libcontainer" замість LXC. Але LXC все ще можна використовувати.


280
2017-09-19 16:21



Схоже, не дивно, щоб включити git в групу інструментів, таких як rpm та dpkg. Я згадую це, тому що бачу спроби використання систем керування версіями, таких як git, як інструмент розповсюдження / пакування, що є джерелом великої плутанини. - blitzen9872
він не помиляється, хоча git може бути використаний для керування пакунками, наприклад, наприклад, внутрішньо в основному ідеальний cli для завантаження тегів git. - roo2
Застосування упаковки в ємностях є цікавим і дієвим підходом. Однак, якщо ви упаковали його в докер, це було б надмірно важким, оскільки не існує прямої підтримки для залежностей або спільних бібліотек. Це саме те, що нові технології упаковки, такі як Ubuntu Snap і Flatpak для Redhat, намагаються досягти. На мій погляд, одна з цих технологій упаковки переможе і стане майбутнім упаковки в linux. - yosefrow


Докер не є методологією віртуалізації. Він спирається на інші інструменти, які фактично використовують віртуалізацію на базі контейнерів або віртуалізацію на рівні операційної системи. Для цього Docker спочатку використовував драйвер LXC, потім перемістився до libcontainer, який зараз перейменовано в runc. Докер в основному зосереджується на автоматизації розгортання додатків всередині контейнерів додатків. Контейнери для додатків призначені для упакування та запуску єдиної служби, тоді як системні контейнери призначені для виконання декількох процесів, таких як віртуальні машини. Отже, Docker розглядається як інструмент управління контейнерами або інструментом розгортання додатків в контейнеризованих системах.

Щоб дізнатись, як він відрізняється від інших віртуалізацій, давайте пройдемо через віртуалізацію та її типи. Тоді було б легше зрозуміти, яка різниця там.

Віртуалізація

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

Гіпервізор

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

Швидкий розвиток технологій віртуалізації, в першу чергу в хмарі, зумовив подальше використання віртуалізації за рахунок створення декількох віртуальних серверів на одному фізичному сервері за допомогою гіпервізорів, таких як Xen, VMware Player, KVM та ін. включення апаратної підтримки в товарних процесорах, таких як Intel VT і AMD-V.

Види віртуалізації

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

  • Емуляція
  • Паравіртуалізація
  • Контейнерна віртуалізація

Емуляція

Емуляція, також відома як повна віртуалізація, повністю керує ядром ОС віртуальної машини в програмному забезпеченні. Гіпервізор, що використовується у цьому типі, відомий як гіпервізор типу 2. Вона встановлюється на вершині операційної системи, яка відповідає за переклад коду ядра гостя ОС до програмних інструкцій. Переклад здійснюється повністю в програмному забезпеченні і не вимагає апаратного залучення. Емуляція дає змогу запускати будь-яку немодифіковану операційну систему, яка підтримує емулюється середовище. Недоліком цього типу віртуалізації є додаткові накладні витрати системних систем, що призводить до зниження продуктивності в порівнянні з іншими видами віртуалізації.

Emulation

Приклади цієї категорії включають VMware Player, VirtualBox, QEMU, Bochs, Parallels та ін

Паравіртуалізація

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

Приклади цієї категорії включають Xen, KVM та ін

Paravirtualization

Контейнерна віртуалізація

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

Container-based virtualization

Концепція контейнера є можливим завдяки функції "імена", додана до ядра Linux версії 2.6.24. Контейнер додає свій ідентифікатор до кожного процесу та додає нові перевірки контролю доступу для кожного системного виклику. Доступ до неї доступний клон () системний виклик, який дозволяє створювати окремі екземпляри попередньо-глобальних просторів імен.

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

Підсистема Linux Control Groups (cgroups), наступний основний компонент для активації віртуалізації на базі контейнерів, використовується для групування процесів та управління їх загальним споживанням ресурсів. Він зазвичай використовується для обмеження споживання пам'яті та процесорів контейнерів. Оскільки контейнеризована система Linux має лише одне ядро, і ядро ​​має повну видимість в контейнерах, існує лише один рівень розподілу ресурсів та планування.

Для контейнерів Linux доступні декілька інструментів керування: LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker тощо.

Контейнери проти віртуальних машин

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

Оскільки віртуалізація на базі контейнерів на машині хоста практично не надає додаткових витрат, віртуалізація на базі контейнерів має близьку продуктивність

Для віртуалізації на базі контейнерів, на відміну від інших віртуалізацій, додаткового програмного забезпечення не потрібно.

Всі контейнери на хост-машині спільно використовують планувальник головної машини, що зберігає потребу в додаткових ресурсах.

Стан контейнера (зображення Docker або LXC) невеликі за розміром у порівнянні з зображеннями віртуальних машин, тому зображення контейнерів легко розподіляються.

Управління ресурсами в контейнерах досягається через групові групи. Cgroups не дозволяє контейнерам споживати більше ресурсів, ніж виділених їм. Однак, на даний момент всі ресурси хост-машини видно на віртуальних машинах, але їх не можна використовувати. Це може бути реалізовано шляхом запуску top або htop на контейнерах і хост машині одночасно. Вихід у всіх середовищах буде виглядати однаково.


124
2018-04-02 00:55



Дуже гарна відповідь. Чи можу я запитати, звідки ви отримали ці діаграми? Оригінальна стаття / книга, тобто. - Harry
Я створив ці діаграми за допомогою Google Малюнків. У мене все ще є користувачі мого облікового запису Google Drawings. - Ashish Bista
А текст? Яке оригінальне джерело тексту для цієї відповіді? - L0j1k
@Sheljohn Перша версія цієї відповіді була скопійована з іншого джерела дослівно без атрибуції. - L0j1k
@AshishBista Ви повинні атрибути / посилання джерела, якщо ви збираєтеся використовувати текст, прийнятий verbatim з де-небудь ще. - L0j1k


Завдяки цьому посту ми збираємося навести деякі рядки відмінностей між віртуальними машинами та LXC. Спочатку визначимо їх.

В.М.:

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

У цьому контексті VM називається гостем під час запуску середовища, який називається хостом.

LXCс:

Контейнери Linux (LXC) - це можливості на рівні операційної системи, які дозволяють запускати кілька ізольованих контейнерів Linux на одному хості керування (хост LXC). Контейнери Linux служать легкою альтернативою віртуальним машинам, оскільки вони не потребують гіпервізорів. Віртуальний бокс, KVM, Xen та ін

Тепер, якщо ви не були наркотиками Алана (Zach Galifianakis - з серії похмілля) і були в Лас-Вегасі протягом останнього року, ви будете добре знати про величезний ривок інтересу до контейнерних технологій Linux, і якщо я буду конкретно один контейнер Проект, який за останні кілька місяців створив популярність в усьому світі, - Докер підкреслив, що середовища для хмарних обчислень повинні відмовитися від віртуальних машин (VM) і замінити їх контейнерами через їхні нижчі накладні витрати та потенційно кращу продуктивність.

Але велике питання: чи можливо це? Чи буде це розумно?

a. LXC обладнані екземпляром Linux. Це може бути різними атрибутами Linux (наприклад, контейнер Ubuntu на хості CentOS, але він все ще Linux). Точно так само контейнери на базі Windows розкриваються в екземплярі Windows, якщо ми дивимося на віртуальні машини, у яких вони мають досить широкий обсяг, і використовуючи гіпервізорів ви не обмежуєтеся операційними системами Linux або Windows.

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

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

Відмова від віртуальних машин не є практичною зараз. Отже, і VM, і LXC мають власне індивідуальне існування та значення.


118
2017-08-26 07:46



Ваша частина "b" вище, це саме те, що люди Докеров казали про цю технологію. Це має на меті зробити розробку і спрощення розгортання. І, виходячи з мого досвіду як dev і як сизоп, я повинен погодитися. - WineSoaked
Це досить абстрактна відповідь. Нам потрібні корисні випадки, коли використовувати / не використовувати Docker. Це питання. Кожен може дізнатись, що таке Докер, але лише деякі з них можуть пояснити реальні сценарії. - Ivan Voroshilin
чи можете ви прояснити частину "a". Мова не дуже зрозуміла. - aamir
Докер зараз вносяться в світ Windows, оскільки він більше не залежить від LXC: blogs.msdn.com/b/nzdev/archive/2015/06/02/... будь ласка, виправте мене, якщо я неправильно зрозумів відповіді тут - bubakazouba
Мені важко зрозуміти "(наприклад, контейнер Ubuntu на хост Centos, але це ще Linux)" частина контейнерів. Як я розумію, це те, що контейнери діляться ядром хоста. Якщо у мене є хост VM, що працює під керуванням Linux kernel 4.6, наприклад, наявність декількох гостьових віртуальних машин під керуванням Linux ядра 2.4, 2.6, 3.2, 4.1 та 4.4. Якщо я виконую команди, специфічні для цього ядра, я отримаю поведінку ядра гостя (а не хоста). Але якщо моїм гостьовим VM є контейнери, чи буде виконана команда визначатись ядром хоста? - Jeach


Більшість відповідей тут говорять про віртуальні машини. Я збираюся надати вам однокласну відповідь на це питання, що найбільше допомогло мені за останні пару років використання Docker. Це так:

Докер - це просто чудовий спосіб запустити процес, а не віртуальну машину.

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

Контейнер Docker - це лише процес (і його діти), який використовується для розділення групами всередині ядра хост-системи від решти процесів. Ви можете побачити ваші процеси контейнерів Docker запуском ps aux на хост. Наприклад, початок apache2 "в контейнері" тільки починається apache2 як особливий процес на хост. Це просто розділено з інших процесів на машині. Важливо зазначити, що ваші контейнери не існують поза вашим контейнеризованим процесом "lifetime". Коли ваш процес вмирає, ваш контейнер вмирає. Це тому, що Докер замінює pid 1 всередині вашого контейнера з вашою заявкою (pid 1 зазвичай є init-системою). Цей останній пункт про pid 1 дуже важливо.

Що стосується файлової системи, яка використовується кожним із процесів контейнерів, то Докер використовує UnionFSЗворотні зображення, які ви завантажуєте, коли ви робите це docker pull ubuntu. Кожне "зображення" - це всього лише серія шарів і відповідні метадані. Тут дуже важлива концепція шарів. Кожен шар - це лише зміна шару під ним. Наприклад, коли ви видаляєте файл у вашому файлі Docker під час створення контейнера Docker, ви насправді просто створюєте шар на верхній частині останнього шару, який говорить, що "цей файл був видалений". До речі, саме тому ви можете видалити великий файл з вашої файлової системи, але зображення все-таки займає ту ж кількість вільного місця на диску. Файл все ще там, у шарах під поточним. Самі шари - це просто копіювання файлів. Ви можете протестувати це з docker save --output /tmp/ubuntu.tar ubuntuі потім cd /tmp && tar xvf ubuntu.tar. Тоді ти можеш озирнутися. Всі ті каталоги, які виглядають як довгі хеші, насправді є окремими шарами. Кожен містить файли (layer.tar) та метадані (json) з інформацією про цей конкретний шар. Ці шари просто описують зміни в файловій системі, які зберігаються як шар "на вершині" його початкового стану. Читаючи "поточні" дані, файлова система читає дані так, наче вона дивиться лише на найвищі шари змін. Ось чому файл, як видається, видаляється, навіть якщо він все ще існує в "попередніх" шарах, оскільки файлова система розглядає лише найвищі шари. Це дозволяє зовсім іншим контейнерам ділитися своїми шаблонами файлової системи, навіть якщо деякі файлові системи можуть мати серйозні зміни у верхніх шарів у кожному контейнері. Це може заощадити на тоні дискового простору, коли ваші контейнери обмінюються основними шарами зображення. Проте, коли ви встановлюєте каталоги та файли з хостової системи у ваш контейнер за обсягами, ці обсяги "обходять" UnionFS, тому зміни не зберігаються в шарах.

Мережа в Docker досягається за допомогою ефірного мосту (називається docker0 на хості) і віртуальні інтерфейси для кожного контейнера на хості. Вона створює віртуальну підмережу docker0 щоб ваші контейнери спілкувалися між собою. Тут існує безліч варіантів створення мережі, зокрема створення спеціальних підмереж для ваших контейнерів, а також можливість "спільного використання" мережевого стека вашого хоста для вашого контейнера для безпосереднього доступу.

Докер рухається дуже швидко. Його документація це найкраща документація, яку я коли-небудь бачив. Вона, як правило, добре написана, лаконічна та точна. Я рекомендую вам перевірити доступну документацію для отримання додаткової інформації та довіряти документації за будь-якою іншою інформацією, яку ви читаєте в Інтернеті, включаючи переповнення стеків. Якщо у вас є конкретні питання, я настійно рекомендую приєднатися #docker на Freenode IRC і запитайте там (ви навіть можете використовувати Freenode's webchat для того!).


91
2018-04-04 02:35



"Докер - це просто чудовий спосіб запустити процес, а не віртуальну машину". це великий підсумок, спасибі! - mkorman
Дякую! Кредит на це виходить програмірам з #docker канал на Freenode IRC. - L0j1k
Це чудова відповідь. Мені сподобалася аналогія. - Teoman shipahi


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


57
2017-08-27 18:25



Я довідаюсь про LXC, виправляю, якщо я помиляюсь, але це може бути якийсь віртуальний номер? але, очевидно, ширше, а не просто навколо python, щоб сказати - NeoVe
Мені подобається ця відповідь найкраще. Це просте і йде прямо до точки. Тепер, коли хтось базується на тому, чого LXC і віртуалізатори можуть зробити, деталі іншого читання матимуть сенс. - Phil
@ Філ. Це відбулося після того, як я прочитав докладні відповіді над ним першим. - johnny


Вони обидва дуже різні. Докер легкий і використовує LXC / libcontainer (який спирається на розташування назв ядер і cgroups) і не має машинну / апаратну емуляцію, таку як гіпервізор, KVM. Xen, які важкі.

Docker і LXC призначені більше для ізольованого програмного забезпечення, контейнеризації та ресурсної ізоляції. Він використовує API клонів хостової ОС (в даний час тільки Linux kernel), який надає місця розташування імен IPC, NS (mount), мережі, PID, UTS і т. Д.

А як щодо пам'яті, введення / виводу, процесора тощо? Це керується за допомогою cgroups, де ви можете створювати групи з певним ресурсом (процесор, пам'ять і т. Д.), Специфікацією / обмеженням і вклавши там ваші процеси. На вершині LXC, Docker забезпечує резервну копію пам'яті (http://www.projectatomic.io/docs/filesystems/), наприклад, файлова система mount union, де ви можете додавати шари та обмінюватися шарами між різними областями імен монтування.

Це потужна функція, коли основні зображення зазвичай використовуються лише для читання, і лише тоді, коли контейнер змінює щось у шасі, він буде писати щось для розділу читання-запису (a.k.a. copy on write). Він також забезпечує багато інших обгортків, таких як реєстр та версію зображень.

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

Звичайна віртуальна машина (наприклад, VirtualBox і VMware) використовує гіпервізор, а суміжні технології мають або спеціальну прошивку, яка стає першим рівнем для першої ОС (ОС хоста або гостьової ОС 0) або програмного забезпечення, що працює на ОС хоста надавати готові операційні системи для забезпечення емуляції апаратних засобів, таких як процесор, USB / аксесуари, пам'ять, мережа тощо. Віртуальні агенти все ще (починаючи з 2015 року) популярні в умовах високоякісного середовища для багатьох мешканців.

Docker / LXC може працювати практично на будь-якому дешевому апаратному забезпеченні (менше 1 ГБ пам'яті також є ОК, якщо у вас нове ядро), а звичайні віртуальні машини потребують щонайменше 2 ГБ пам'яті тощо, щоб зробити щось змістовне . Але підтримка Docker на операційній системі ОС недоступна в операційній системі, такої як Windows (станом на червень 2014 року), де типи віртуальних машин можуть працювати на Windows, Linux та Mac.

Ось фото з docker / rightscale: Here is a pic from rightscale


45
2017-11-03 17:44