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

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

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

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

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

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

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

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

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

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

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

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

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

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

З коментарів ...

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

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

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

Джерело

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

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

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

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

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

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

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

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

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

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

Для мене це відповідає розриву між інструментами, орієнтованими на розробників, такими як rpm, пакети Debian , Maven , npm + Git з одного боку та такі інструменти, як Puppet , VMware, Xen, ви називаєте це ...

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

Ваше запитання передбачає певну послідовність виробничого середовища. Але як це тримати послідовно? Розглянемо деяку кількість (> 10) серверів і додатків, етапів у конвеєрі.

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

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

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

І нарешті, ви навіть часто зможете відтворювати складні виробничі середовища навіть на своєму ноутбуці Linux (не дзвоніть мені, якщо у вашому випадку не працює;))

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

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

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

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

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

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

Гіпервізор

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

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

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

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

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

Емуляція

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

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

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

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

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

Віртуалізація на основі контейнерів

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

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

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

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

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

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

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

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

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

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

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

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

Оновлення:

Як Docker запускає контейнери в нелінукс-системи?

Якщо контейнери можливі через функції, доступні в ядрі Linux, очевидним питанням є те, як нелінукс системи запускають контейнери. І Docker для Mac і Windows використовують для управління контейнерами VM для Linux. Docker Toolbox використовується для запуску контейнерів у віртуальних віртуальних колах. Але останній Docker використовує Hyper-V в Windows та Hypervisor.framework в Mac.

Тепер дозвольте мені описати, як Docker для Mac детально запускає контейнери.

Docker для Mac використовує https://github.com/moby/hyperkit для імітації можливостей гіпервізора, а Hyperkit використовує гіпервізор.framework у своїй основі. Hypervisor.framework - це рідне рішення для гіпервізорів Mac. Hyperkit також використовує VPNKit та DataKit для мережі імен та файлової системи відповідно.

Linux VM, який Docker працює на Mac, доступний лише для читання. Однак ви можете врізатися в нього, запустивши:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Тепер ми навіть можемо перевірити версію Kernel цього VM:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Всі контейнери працюють всередині цього віртуального комп'ютера.

Існують деякі обмеження щодо hipervisor.framework. Через це Docker не відкриває docker0мережевий інтерфейс у Mac. Отже, ви не можете отримати доступ до контейнерів від хоста. На сьогоднішній день docker0доступний лише всередині VM.

Hyper-v - це рідний гіпервізор у Windows. Вони також намагаються використати можливості Windows 10 для запуску Linux систем.

Через цю посаду ми збираємося провести деякі відмінності між VM та LXC. Давайте спочатку визначимо їх.

ВМ :

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

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

LXC s:

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

Тепер, якщо ви не потрапили під наркотики Аланом (Зак Галіфіанакіс - із серії Hangover) і не були у Вегасі останній рік, ви будете добре обізнані про надзвичайний інтерес до технології контейнерів Linux, і якщо я буду конкретний один контейнер Проект, який створив шум у всьому світі за останні кілька місяців, - Докер, що призводить до деяких повторюваних думок про те, що хмарні обчислювальні середовища повинні відмовитися від віртуальних машин (ВМ) і замінити їх контейнерами через їхні менші накладні витрати та потенційно кращі показники.

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

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

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

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

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

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

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

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

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

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

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

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

Docker інкапсулює додаток з усіма його залежностями.

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

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

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

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

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

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

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

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

Ось картинка з docker / rightscale:

1. Легкий

Це, мабуть, перше враження для багатьох учнів, які навчаються докерів.

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

По-друге, контейнери Docker можуть запускатися за кілька мілісекунд, а VM - за секунди.

2. Шарова файлова система

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

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

3. Спільне ядро ​​ОС

Розглядайте контейнери як процеси!

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

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

Чому це важливо?

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

Подумайте про розгортання програми. Якщо ми хочемо розгорнути нове програмне забезпечення (послугу) або оновити його, краще змінити конфігураційні файли та процеси, а не створювати новий VM. Оскільки для створення VM з оновленою послугою, тестування його (частка між Dev & QA), розгортання до виробництва займає години, навіть дні. Якщо щось піде не так, ви повинні почати заново, витрачаючи ще більше часу. Таким чином, використовуйте інструмент управління конфігурацією (ляльковий, соляний кухар, шеф-кухар тощо) для встановлення нового програмного забезпечення, бажано завантажувати нові файли.

Що стосується докера, неможливо використовувати новостворений контейнер докера для заміни старого. Обслуговування набагато простіше! Створіть новий образ, діліться ним із QA, тестуйте його, розгортайте його лише за кілька хвилин (якщо все автоматизовано), години в гіршому випадку. Це називається незмінна інфраструктура : не підтримуйте (оновляйте) програмне забезпечення, не створюйте нове.

Це перетворює спосіб надання послуг. Ми хочемо додатків, але повинні підтримувати VM (що болить і мало стосується наших програм). Docker змушує вас зосереджуватись на додатках і згладжує все.

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

У Docker контейнери, що працюють, мають спільне ядро ​​хост ОС, тоді як у VM вони мають власні файли ОС. Середовище (ОС), в якому ви розробляєте додаток, було б однаковим, коли ви розгортаєте його в різних обслуговуючих середовищах, таких як "тестування" або "виробництво".

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

У наведеному нижче прикладі хост-машина має три VM. Для того, щоб забезпечити додаткам у віртуальних машинах повна ізоляція, у кожного з них є власні копії файлів ОС, бібліотек та коду програми, а також повноцінний екземпляр пам'яті ОС. Тоді як на малюнку нижче показаний той самий сценарій з контейнерами. Тут контейнери просто ділять операційну систему хоста, включаючи ядро ​​та бібліотеки, тому їм не потрібно завантажувати ОС, завантажувати бібліотеки або оплачувати приватну вартість пам'яті за ці файли. Єдине додаткове місце, яке вони займають, - це будь-яка пам'ять і дисковий простір, необхідний для запуску програми в контейнері. У той час як середовище програми відчуває себе виділеною ОС, програма розгортається так само, як і на виділеному хості. Контейнерна програма запускається за лічені секунди, і багато інших прикладів програми можуть поміститися на машині, ніж у корпусі VM.

Джерело: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Існують три різні установки, які надають стек для запуску програми (Це допоможе нам розпізнати, що таке контейнер і що робить його настільки потужним, ніж інші рішення):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) Традиційний стек серверів складається з фізичного сервера, який працює з операційною системою та вашим додатком.

Переваги:

• Використання сировинних ресурсів

• Ізоляція

Недоліки:

• Дуже повільний час розгортання
• Дорогий
• Марно витрачені ресурси
• Складно масштабувати
• Складно мігрувати
• Складна конфігурація

2) Стек VM складається з фізичного сервера, на якому працює операційна система, і гіпервізора, який керує вашою віртуальною машиною, спільними ресурсами та мережевим інтерфейсом. Кожен Vm працює з гостьовою операційною системою, додатком або набором програм.

Переваги:

• Гарне використання ресурсів
• Легко масштабувати
• Легке резервне копіювання та міграція
• Ефективність витрат
• Гнучкість

Недоліки:

• Розподіл ресурсів є проблематичним
• Замок продавця
• Складна конфігурація

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

Переваги:

• Ізоляція
• Легкий
• Ефективний ресурс
• Легко мігрувати
• Безпека
• Низькі накладні
• Середовище виробництва та розвитку дзеркал

Недоліки:

• Та ж архітектура
• Ресурси важких додатків
• Питання мереж та безпеки.

Порівнюючи налаштування контейнера з його попередниками, ми можемо зробити висновок, що контейнеризація - це найшвидший, найефективніший та найбезпечніший параметр, про який ми знаємо на сьогоднішній день. Контейнери - це окремі екземпляри, які запускають вашу програму. Docker закручує контейнер таким чином, шари отримують пам’ять часу запуску з драйверами зберігання за замовчуванням (драйвери накладення), які працюють протягом декількох секунд, і шар копіювання при записі створюється поверх нього, як тільки ми вводимо в контейнер, що забезпечує виконання контейнери.У випадку використання віртуальних машин, це займе близько хвилини, щоб завантажити все у віртуальне середовище. Ці легкі екземпляри можна легко замінити, відновити та перемістити. Це дозволяє нам відобразити виробниче та виробниче середовище і надзвичайно допомагає в процесах CI / CD. Переваги, які контейнери можуть надати, є настільки переконливими, що вони, безумовно, тут, щоб залишитися.

У зв'язку з, щодо:-

"Чому розгортати програмне забезпечення на зображення докера простіше, ніж просто розгортати до послідовного виробничого середовища?"

Більшість програмного забезпечення розгорнуто в багатьох середовищах, як правило, як мінімум три з наступних:

1. Індивідуальні ПК для розробників
2. Спільне середовище для розробників
3. Індивідуальні ПК-тестери
4. Спільне тестове середовище
5. Якість середовища
6. Середовище UAT
7. Тестування навантаження / працездатності
8. Постановка в прямому ефірі
9. Виробництво
10. Архів

Також слід враховувати такі фактори:

• Всі розробники, і справді тестери, матимуть тонкі або дуже різні конфігурації ПК за самою природою завдання
• Розробники часто можуть розробляти на персональних комп'ютерах поза контролем корпоративних або правил стандартизації бізнесу (наприклад, фрілансери, які розробляють на власних машинах (часто віддалено), або учасники проектів з відкритим кодом, які не «працюють» або «контрактують», щоб налаштувати свої ПК на певні спосіб)
• Деякі середовища будуть складатися з фіксованої кількості декількох машин у конфігурації, збалансованої навантаженням
• У багатьох виробничих середовищах буде створено та знищено хмарні сервери, які динамічно (або "еластично") створюються та знищуються залежно від рівня трафіку

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

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

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

Є багато відповідей, які детальніше пояснюють відмінності, але ось моє дуже коротке пояснення.

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

У Docker контейнери ділять ядро з хостом; отже, він легкий і може швидко запускатися і зупинятися.

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

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

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

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

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

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

Джерело: Kubernetes in action.

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

Docker був розроблений на базі LXC (Linux Container) і прекрасно працює в багатьох дистрибутивах Linux, особливо Ubuntu.

Докер-контейнери - це ізольоване середовище. Ви можете побачити це, коли ви видаєте topкоманду в контейнері Docker, який був створений із зображення Docker.

Крім того, вони дуже легкі та гнучкі завдяки конфігурації dockerFile.

Наприклад, ви можете створити Docker-образ і налаштувати DockerFile і сказати, що, наприклад, коли він працює, тоді wget 'this', apt-get 'that', запустіть 'деякі сценарії оболонки', встановивши змінні середовища тощо.

У мікро-сервісних проектах та архітектурі Docker є дуже життєздатним надбанням. Ви можете досягти масштабованості, стійкості та еластичності за допомогою Docker, Docker рій, Kubernetes і Docker Compose.

Ще одне важливе питання щодо Docker - це Docker Hub та його громада. Наприклад, я реалізував екосистему для моніторингу кафки за допомогою Prometheus, Grafana, Prometheus-JMX-Exporter та Docker.

Для цього я завантажив налаштовані контейнери Docker для zookeeper, kafka, Prometheus, Grafana та jmx-collector, після чого встановив власну конфігурацію для деяких з них за допомогою файлів YAML або для інших, я змінив деякі файли та конфігурацію в контейнері Docker, і я побудувати цілу систему моніторингу кафки за допомогою багатоконтейнерних докерів на одній машині з ізоляцією, масштабуванням та стійкістю, що цю архітектуру можна легко перемістити на декілька серверів.

Окрім сайту Docker Hub, є ще один сайт під назвою quay.io, який ви можете використовувати, щоб мати там свої панелі приладів зображень Docker і тягнути / натиснути на / з неї. Ви навіть можете імпортувати зображення Docker з Docker Hub на набережну, а потім запускати їх з набережної на власній машині.

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

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

Ось як представлений Докер :

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

Тож Docker - це контейнер, тобто у вас є зображення та контейнери, які можна запустити на вашій поточній машині. Це не включає операційну систему, як VM s, а як пакет різних робочих пакетів, таких як Java, Tomcat тощо.

Якщо ви розумієте контейнери, ви отримаєте, що таке Docker і чим він відрізняється від VM s ...

Отже, що таке контейнер?

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

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

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

Для мене принциповою відмінністю VM від Docker є те, як ви керуєте просуванням своєї програми.

За допомогою VM ви просуваєте свою програму та її залежність від одного VM до наступного DEV до UAT до PRD.

1. Часто ці VM мають різні патчі та бібліотеки.
2. Не рідкість для декількох додатків спільний доступ до VM. Для цього потрібно керувати конфігурацією та залежностями для всіх програм.
3. Резервне копіювання вимагає скасування змін у віртуальній машині. Або відновити його, якщо можливо.

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

1. За винятком ядра, патчі та бібліотеки однакові.
2. Як правило, існує лише одна програма на контейнер, яка спрощує конфігурацію.
3. Резервне копіювання складається із зупинки та видалення контейнера.

Таким чином, на самому фундаментальному рівні за допомогою VM ви рекламуєте додаток та його залежності як дискретні компоненти, тоді як з Docker ви просуваєте все одним хітом.

І так, є проблеми з контейнерами, включаючи управління ними, хоча такі інструменти, як Kubernetes або Docker Swarm значно спрощують завдання.