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

33

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?

slm
fuente
3
Si bien no es preciso (y por qué no voy a escribirlo como respuesta), me resulta más fácil pensar en Docker como un chroot elegante que como una máquina virtual. Eso no es exacto, pero ayuda cuando intento visualizarlo en mi cabeza.
coteyr
2
@coteyr: es curioso que mencione esa analogía, utilicé esa exacta al intentar describir lo que Docker también está haciendo. IMO Docker tiene mucho más en común con chroot que con la virtualización.
slm

Respuestas:

53

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:

    ss01

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:

    ss02

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.

    ss03

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:

    ss04

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

    ss05

¿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í:

    ss06

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.

slm
fuente
Además, Docker crea un espacio de usuario aislado por contenedor en ejecución.
Bhargav Nanekalva el
3

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.

mckenzm
fuente
1
Editado, estaba pensando con una gorra de Xen heredada. Claramente, ese no es el caso cuando se ejecuta Windows en KVM / Qemu o se ejecuta una VM de 64 bits en un host de 32 bits en VirtualBox. (no preguntes) Es similar al argumento pv vs hvm para AWS.
mckenzm