Docker не є методологією віртуалізації. Він спирається на інші інструменти, які фактично реалізують віртуалізацію віртуалізації на рівні контейнерів або операційної системи. Для цього Docker спочатку використовував драйвер LXC, а потім перейшов в libcontainer, який тепер перейменований в runc. Docker в першу чергу фокусується на автоматизації розгортання додатків всередині контейнерів додатків. Контейнери додатків призначені для упаковки і запуску єдиної служби, тоді як системні контейнери призначені для запуску декількох процесів, таких як віртуальні машини. Таким чином, Docker розглядається як засіб управління контейнерами або розгортання додатків на контейнеризовано системах.
Щоб дізнатися, як він відрізняється від інших віртуалізації, відпустіть віртуалізацію і її типи. Тоді було б легше зрозуміти, в чому різниця.
Віртуалізація
У своїй задуманої формі він розглядався як метод логічного поділу мейнфреймів, що дозволяє одночасно запускати кілька додатків. Однак сценарій різко змінився, коли компанії та спільноти з відкритим вихідним кодом змогли забезпечити спосіб обробки привілейованих інструкцій так чи інакше і дозволити одночасного запуску декількох операційних систем на одній системі на основі x86.
гипервизор
Гипервизор обробляє створення віртуального середовища, на якій працюють гостьові віртуальні машини. Він контролює гостьові системи і гарантує, що ресурси будуть виділені для гостей в міру необхідності. Гипервизор знаходиться між фізичною машиною і віртуальними машинами і надає послуги віртуалізації віртуальним машинам. Щоб реалізувати це, він перехоплює операції гостьовий операційної системи на віртуальних машинах і емулює операцію в операційній системі хост-машини.
Швидкий розвиток технологій віртуалізації, перш за все в хмарі, призвело до подальшого використання віртуалізації, дозволяючи створювати кілька віртуальних серверів на одному фізичному сервері за допомогою гіпервізора, таких як Xen, VMware Player, KVM і т.д .., і включення апаратної підтримки в товарні процесори, такі як Intel VT і AMD-V.
типи віртуалізації
Метод віртуалізації можна класифікувати на основі того, як він імітує апаратне забезпечення гостьовий операційної системи і емулює гостьову операційну середу. Перш за все, існує три типи віртуалізації:
- емуляція
- Паравіртуалізація
- контейнерна віртуалізація
Emulation
Емуляція, також відома як повна віртуалізація, повністю запускає ядро ОС віртуальної машини в програмному забезпеченні. Гипервизор, який використовується в цьому типі, відомий як гипервизор типу 2. Він встановлюється на вершині операційної системи хоста, яка відповідає за переклад коду ядра гостьової ОС на інструкції програмного забезпечення. Переклад повністю виконаний в програмному забезпеченні і не вимагає участі обладнання. Емуляція дозволяє запускати будь-яку немодифіковані операційну систему, яка підтримує емуляцію середовища. Недоліком цього типу віртуалізації є додаткове навантаження на системні ресурси, що призводить до зниження продуктивності в порівнянні з іншими виртуализацией.
Приклади цієї категорії включають VMware Player, VirtualBox, QEMU, Bochs, Parallels і т.д.
Паравіртуалізація
Паравіртуалізація, також відома як гипервизор типу 1, запускається безпосередньо на апаратному забезпеченні або "голом" і надає послуги віртуалізації безпосередньо віртуальним машинам, які працюють на ньому. Це допомагає операційній системі, віртуалізувати обладнання та реальному обладнанню співпрацювати для досягнення оптимальної продуктивності. Ці Гіпервізор зазвичай мають досить невеликий розмір і самі по собі не вимагають значних ресурсів.
Приклади в цій категорії включають Xen, KVM і т.д.
Віртуалізація на основі контейнерів
Контейнерна віртуалізація, також відома як віртуалізація на рівні операційної системи, дозволяє виконувати кілька ізольованих виконань в одному ядрі операційної системи. Він має найкращу продуктивність і щільність, а також динамічне управління ресурсами. Ізольована віртуальне середовище виконання, що надається цим типом віртуалізації, називається контейнером і може розглядатися як відстежувана група процесів.
Концепція контейнера стає можливою завдяки функції namespaces, доданої в ядро Linux 2.6.24. Контейнер додає свій ідентифікатор до кожного процесу і додає нові перевірки контролю доступу до кожного системного виклику. До нього звертається системний виклик clone (), який дозволяє створювати окремі екземпляри раніше глобальних просторів імен.
Простору імен можуть використовуватися різними способами, але найбільш поширеним є створення ізольованого контейнера, який не має видимості або доступу до об'єктів поза контейнера. Процеси, запущені всередині контейнера, працюють в нормальній системі Linux, хоча вони спільно використовують базове ядро з процесами, розташованими в інших просторах імен, однаковими для інших об'єктів. Наприклад, при використанні просторів імен користувач root всередині контейнера не обробляється як root поза контейнера, додаючи додаткову безпеку.
Підсистема Linux-груп (cgroups), наступний головний компонент для віртуалізації на основі контейнерів, використовується для угруповання процесів і управління їх сукупним споживанням ресурсів. Він зазвичай використовується для обмеження споживання пам'яті та процесора в контейнерах. Оскільки в контейнеризовано системі Linux є тільки одне ядро, і ядро має повну видимістю в контейнерах, існує тільки один рівень розподілу ресурсів і планування.
Для Linux-контейнерів доступні кілька інструментів управління, включаючи LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker і т.д.
Контейнери проти віртуальних машин
На відміну від віртуальної машини, контейнеру не потрібно завантажувати ядро операційної системи, тому контейнери можуть бути створені менш ніж за секунду. Ця особливість робить віртуалізацію на основі контейнерів унікальною і бажаною, ніж інші підходи до віртуалізації.
Оскільки віртуалізація на основі контейнерів додає невеликі або взагалі не накладні витрати на хост-машину, віртуалізація на основі контейнерів має майже власну продуктивність
Для віртуалізації на основі контейнера додаткове програмне забезпечення не вимагається, на відміну від інших віртуалізації.
Всі контейнери на хост-машині спільно використовують планувальник хост-комп'ютера, що вимагає додаткових ресурсів.
Контейнерні стану (зображення Docker або LXC) невеликі в порівнянні з зображеннями віртуальної машини, тому зображення контейнерів легко розподіляються.
Управління ресурсами в контейнерах здійснюється через групи. Cgroups не дозволяє контейнерів споживати більше ресурсів, ніж виділено ім. Однак на даний момент всі ресурси хост-машини видно на віртуальних машинах, але не можуть використовуватися. Це можна реалізувати, виконавши top або htop на контейнерах і хост-машині одночасно. Висновок у всіх середовищах буде схожий.