0
484
Vistas¿Es el motor de contenedor una capa completa entre el sistema operativo y las aplicaciones o simplemente otra aplicación que se ejecuta junto a otras aplicaciones encima del sistema operativo?
En la mayoría de los tutoriales, publicaciones e incluso algunas publicaciones de blog de Docker, el motor de contenedor se ilustra como una capa completa que se encuentra sobre el sistema operativo. También se considera como un hipervisor o una capa que realiza la virtualización e incluso a veces se denomina virtualización ligera o virtualización a nivel de sistema operativo.
Pero la verdad es que las aplicaciones se ejecutan directamente en el sistema operativo y todas comparten el mismo núcleo. El motor del contenedor no interpreta ni traduce ningún código para ejecutarlo en el sistema operativo subyacente.
También leí en qué se diferencia Docker de una máquina virtual, pero se trata principalmente de la diferencia entre las máquinas virtuales y los contenedores, pero mi pregunta es específicamente sobre los motores de contenedores.
¿Es correcto ilustrar el motor de contenedor como una capa completa entre el sistema operativo y las aplicaciones (figura 1) o debe considerarse simplemente como un proceso que se ejecuta junto a otras aplicaciones sobre el sistema operativo (figura 2)?
3 Respuestas
Responde la pregunta0
¿Es un motor de contenedor una capa completa entre el sistema operativo y las aplicaciones?
No.
¿Es un motor de contenedor otra aplicación que se ejecuta junto a otras aplicaciones encima del sistema operativo?
Esta definición es mejor.
Scott McCarty tiene la siguiente diapositiva en una de sus presentaciones:
Sigue un poco de historia que podría ayudar con términos como docker daemon , containerd , runc , rkt ...
de: documentación de CoreOS :
Antes de la versión 1.11 de Docker, el demonio del motor de Docker descargaba imágenes de contenedores, iniciaba procesos de contenedores, exponía una API remota y actuaba como un demonio de recopilación de registros, todo en un proceso centralizado que se ejecutaba como raíz .
Si bien una arquitectura tan centralizada es conveniente para la implementación, no sigue las mejores prácticas para la separación de procesos y privilegios de Unix; Además, hace que Docker sea difícil de integrar correctamente con los sistemas de inicio de Linux, como upstart y systemd.
Desde la versión 1.11, el demonio Docker ya no maneja la ejecución de los contenedores por sí mismo. En cambio, esto ahora lo maneja containerd . Más precisamente, el demonio de Docker prepara la imagen como un paquete de imagen de contenedor abierto (OCI) y realiza una llamada API a containerd para iniciar el paquete OCI. containerd luego inicia el contenedor usando runC
Otras lecturas:
0
Depende de cómo quieras mirarlo.
En Docker, los contenedores son básicamente procesos secundarios de los procesos de Docker y, además, están configurados para estar restringidos por misc. características del kernel como espacios de nombres o cgroups.
Entonces, si bien los procesos del contenedor pueden pensar que se ejecutan sobre el kernel, es una ilusión creada por Docker y creada por las características del kernel.
Y si uno piensa que la ilusión cuenta como una capa separada de "Container Engine" es un asunto personal. (En mi humilde opinión, es básicamente el tipo de problema "vim vs Emacs").
0
Al responder a su pregunta, las imágenes del contenedor se convierten en contenedores en tiempo de ejecución y, en el caso de los contenedores de Docker, las imágenes se convierten en contenedores cuando se ejecutan en Docker Engine. Pero como en la mayoría de las imágenes de la arquitectura de contenedores, el motor docker se implementa en toda la capa entre el sistema operativo host y la aplicación contenerizada porque el objetivo de la arquitectura contenerizada es construir solo una aplicación contenerizada en la parte superior.
Entonces, si no desea implementar solo una aplicación contenerizada sobre el sistema operativo, no tiene que usar Docker Engine y eso implica que Docker Engine no tiene que usarse e implementarse en todo el nivel de la arquitectura de Docker. Al crear dicha arquitectura, depende de usted si desea asignar una capa completa en el motor de la ventana acoplable y asumir que todas las aplicaciones en su entorno se contendrán.
Podemos definir Docker Engine como el tiempo de ejecución (es una aplicación cliente-servidor) y las herramientas que permiten que las aplicaciones de contenedor, definidas por un Dockerfile, se ejecuten sobre un sistema operativo host en una sección aislada de "contenedor".
Espero que ayude.