Diferencia entre chroot y Docker

15

No entiendo la diferencia entre docker y chroot. Sí, es agradable en términos del embalaje del registro. Pero de alguna manera tengo la sensación de que es simplemente chroot con campanas y silbatos adicionales.

Sé que me estoy perdiendo algo. Sería genial saber cómo son diferentes y la necesidad de Docker si Chroot podría hacer algo similar.

No pude encontrar este Chroot Vs Docker lo suficientemente claro tampoco.

docker linux containers Vipin Menon
fuente
Bueno, sí, Docker no hace nada que el núcleo ya no haga por ti. Simplemente lo empaqueta en una herramienta más o menos coherente y bastante fácil de usar. Puede crear su propio Docker si se molesta en hacer chroot, espacios de nombres, cuotas, NAT y todo lo demás usted mismo.
Cayo

Respuestas:

8

Bueno, las campanas y silbatos adicionales se llaman aislamiento del proceso, un contenedor obtiene su propio espacio de nombres del núcleo del host, lo que significa que el programa en el contenedor no puede intentar leer la memoria del núcleo o comer más RAM de la permitida.

También aísla las pilas de red, por lo que dos procesos pueden escuchar en el puerto 8080 por ejemplo, tendrá que manejar el enrutamiento a nivel de host, no hay magia aquí, pero esto permite manejar el enrutamiento en un lugar y evitar modificar la configuración del proceso para Escucha un puerto libre.

En segundo lugar, un chroot sigue siendo de lectura / escritura, cualquier cambio es permanente, un contenedor acoplable que aufsse iniciará desde un sistema de archivos limpio cada vez que inicie el contenedor (los cambios se mantienen si lo detiene / inicia IIRC).

Entonces, si bien un contenedor puede considerarse como process namespace+ chroot, la realidad es un poco más compleja.

Tensibai
fuente
Tenga en cuenta que aufsya no se usa por defecto. Ahora esoverlay2
Vitalii Vitrenko
Es cierto, pero creo que hay más materiales educativos que hacen referencia a aufs que overlay2 por ahora :)
Tensibai
Un proceso normal no puede leer ninguna memoria que tampoco se supone que debe leer. Si confías en Docker por seguridad, lo estás haciendo mal ...
Gaius
@Gaius, me estás leyendo mal, solo estoy tratando de dar pistas de búsqueda al OP ... Agregar Docker en una tubería de entrega con toda la libertad que le da al desarrollador a lo que usan dentro no es absolutamente un punto de seguridad. Sin embargo, los espacios de nombres protegen de un montón de desbordamiento de pila y desbordamiento de búfer por naturaleza.
Tensibai
5

Sí, absolutamente hay más que chroothasta el punto de que tienen poco o nada en común.

  • Un formato de archivo de script estandarizado que incluye semántica relacionada con la tarea de una mano
  • Imágenes (incluidas imágenes anónimas intermedias), almacenamiento en caché, nomenclatura, descarga, etc., incluida una gestión eficaz ( docker image prune...)
  • Contenedores (incluidos sus propios sistemas de archivos temporales, nombres, acceso a docker execellos, etc.)
  • Gestión de procesos ( docker container ...)
  • Redes con solo una opción simple, que incluye redes de contenedores internos, etc.
  • Volúmenes (incluidos los volúmenes gestionados especiales)
  • docker-compose o enjambre como actualizaciones de bajo perfil a mucho más.
  • El gran zoológico de otras soluciones basadas en contenedores dockerizados (OpenShift, etc.).
AnoE
fuente