Як виглядають процеси всередині контейнера Docker?

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

Може хтось, будь ласка, надати високий рівень огляду того, що відбувається?

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

Однак Docker не робить нічого магічного щодо віртуалізації апаратних засобів системи. Швидше він використовує можливість Linux Kernel будувати "огорожі" навколо ключових об'єктів, що дозволяє процесу взаємодії з такими ресурсами, як мережа, файлова система та дозволи (серед іншого), створюючи ілюзію, що ви взаємодієте з повністю функціональною системою.

Ось приклад, який ілюструє, що відбувається, коли ми запускаємо контейнер Docker і потім вводимо його через виклик /bin/bash.

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

Тепер зсередини цього контейнера, якщо ми запустимо ps -eaf:

Перейшовши на іншу вкладку терміналу, де ми входимо в систему хосту, яка розміщує контейнер Docker, ми можемо побачити простір процесу, який контейнер "насправді" займає:

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

ПРИМІТКА . Процеси - це 4 sleep 1000команди, які перебувають у фоновому режимі.

Зверніть увагу, як усередині контейнера Docker процесам присвоюються ідентифікатори процесу (PID) 48-51. Дивіться їх у ps -eafвисновку також:

Однак із цим наступним зображенням розкривається значна частина «магії», яку виконує Докер.

Подивіться, як ці 4 sleep 1000процеси насправді є лише дочірніми процесами до нашого оригінального процесу Bash? Також врахуйте, що наш оригінальний контейнер Docker /bin/bashнасправді є дочірнім процесом до демона Docker.

Тепер, якщо нам слід було зачекати 1000+ секунд, щоб оригінальні sleep 1000команди закінчилися, а потім запустіть ще 4 нові та запустимо ще один контейнер Docker таким чином:

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

Вихід хост-комп'ютера ps -eafбуде виглядати приблизно так:

І інші контейнери Docker, всі вони просто відображатимуться як процеси під демоном Docker.

Отже, Ви бачите, що Docker насправді не віртуалізує ( у традиційному розумінні ), він будує "огорожі" навколо різних ресурсів Kernel і обмежує видимість для них для певного процесу + дітей.

Всередині контейнера ваші процеси повинні бути ізольованими (під карантином). Насправді ви не повинні бачити будь-які процеси, крім тих, які ви вказали (принаймні оболонки). Це не для тестування на "товариськість". Єдина схожість з chroot полягає в тому, що використовується головне ядро. Docker чудовий, якщо вам потрібно щось ізолювати або використовувати інші версії програмного забезпечення архітектури платформи, ніж ті, що працюють на хості. (кажуть дуже старі версії Java або інша вилка Python). Будьте чітко в курсі, що папки та двійкові файли, з якими ви маєте справу, не можуть бути такими, як у хості. Це не та сама папка / бін тощо.

EDIT: схожість з chroot, а не VM.