Как выглядят процессы внутри контейнера Docker?

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

Может ли кто-нибудь предоставить общий обзор того, что происходит?

Docker попадает в ведро виртуализации, потому что люди предполагают, что это каким-то образом виртуализирует аппаратное обеспечение под ним. Это неправильный термин, который пронизывает терминологию, которую использует Docker, главным образом термин «контейнер».

Однако Docker не делает ничего волшебного в отношении виртуализации оборудования системы. Скорее, он использует способность ядра Linux создавать «ограждения» вокруг ключевых средств, что позволяет процессу взаимодействовать с такими ресурсами, как сеть, файловая система и разрешения (среди прочего), чтобы создать иллюзию того, что вы взаимодействуете. с полностью функциональной системой.

Вот пример, который иллюстрирует, что происходит, когда мы запускаем контейнер 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выводе в их также:

Тем не менее, с этим следующим изображением раскрывается большая часть «магии», которую исполняет Docker.

Посмотрите, как эти 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 на самом деле не виртуализируется ( в традиционном смысле ), он создает «ограждения» вокруг различных ресурсов ядра и ограничивает их видимость для данного процесса + потомков.

Внутри контейнера ваши процессы должны быть изолированы (помещены в карантин). На самом деле вы не должны видеть никаких процессов, кроме тех, которые вы укажете (по крайней мере, оболочка). Это не для проверки "общительности". Единственное сходство с chroot в том, что используется ядро ​​хоста. Docker отлично подходит, если вам нужно что-то изолировать или использовать версии программного обеспечения для архитектуры платформы, отличные от той, которая работает на хосте. (говорят очень старые версии Java или другой форк Python). Помните, что папки и двоичные файлы, с которыми вы имеете дело, могут не совпадать с папками на хосте. Это не та же папка / bin и т. Д.

РЕДАКТИРОВАТЬ: сходство с chroot, а не виртуальных машин.