¿Cómo son los procesos dentro de un contenedor Docker?

Recientemente he escuchado confusión varias veces sobre lo que es un contenedor Docker, y más específicamente lo que está sucediendo dentro, con respecto a los comandos y procesos que invoco dentro de un contenedor Docker.

¿Alguien puede proporcionar una visión general de alto nivel de lo que está sucediendo?

Docker es arrojado al cubo de virtualización, porque la gente asume que de alguna manera está virtualizando el hardware debajo. Este es un nombre inapropiado que impregna la terminología que utiliza Docker, principalmente el término contenedor.

Sin embargo, Docker no está haciendo nada mágico con respecto a la virtualización del hardware de un sistema. Más bien está haciendo uso de la capacidad del Kernel de Linux para construir "cercas" alrededor de las instalaciones clave, lo que permite que un proceso interactúe con recursos como la red, el sistema de archivos y los permisos (entre otras cosas) para dar la ilusión de que está interactuando con un sistema completamente funcional.

Aquí hay un ejemplo que ilustra lo que sucede cuando iniciamos un contenedor Docker y luego lo ingresamos mediante la invocación de /bin/bash.

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

Ahora desde dentro de este contenedor, si corremos ps -eaf:

Cambiando a otra pestaña de terminal donde estamos conectados al sistema host que aloja el contenedor Docker, podemos ver el espacio de proceso que el contenedor está "realmente" ocupando:

Ahora, si volvemos a la pestaña Docker e iniciamos varios procesos dentro de él y los ejecutamos en segundo plano, podemos ver que ahora tenemos varios procesos secundarios que se ejecutan en el proceso Bash primario que comenzamos originalmente como parte del lanzamiento del contenedor Docker.

NOTA: Los procesos son 4 sleep 1000comandos que están en segundo plano.

Observe cómo, dentro del contenedor Docker, se asignan ID de proceso (PID) a los procesos de 48-51. Véalos en elps -eaf salida en su también:

Sin embargo, con esta siguiente imagen, se revela gran parte de la "magia" que Docker está realizando.

¿Ves cómo los 4 sleep 1000procesos son en realidad solo procesos secundarios para nuestro proceso Bash original? También tenga en cuenta que nuestro contenedor Docker original /bin/bashes, de hecho, un proceso secundario para el demonio Docker también.

Ahora si tuviéramos que esperar más de 1000 segundos para el original sleep 1000 que finalicen los comandos , y luego ejecutar 4 nuevos más, e iniciar otro contenedor Docker así:

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

La salida de la computadora host ps -eafse vería así:

Y otros contenedores Docker, todos aparecerán como procesos bajo el demonio Docker.

Como puede ver, Docker realmente no está virtualizando ( en el sentido tradicional ), está construyendo "cercas" alrededor de los diversos recursos del Kernel y limitando su visibilidad para un proceso dado + hijos.

Dentro del contenedor, sus procesos deben estar aislados (en cuarentena). De hecho, no debería ver ningún proceso que no sean los que especifique (al menos un shell). No es para pruebas de "sociabilidad". La única similitud con chroot es que se usa el núcleo del host. Docker es excelente si necesita aislar algo o usar versiones de software de arquitectura de plataforma diferentes a las que se ejecutan en el host. (versiones muy antiguas de Java o una bifurcación diferente de Python, por ejemplo). Tenga en cuenta que las carpetas y los archivos binarios con los que está tratando pueden no ser los mismos que los del host. No es la misma carpeta / bin, etc.

EDITAR: similitud con chroot en lugar de máquinas virtuales.