En agosto de 2013, Jérôme Petazzoni creó Docker en Docker, dindpara abreviar, esto permitió que se crearan contenedores Docker dentro de Docker Containers, esta funcionalidad resultó muy popular, lo que resultó en que el repositorio GitHub de Jérôme recibiera más de mil estrellas y trescientos tenedores.

A partir de Docker 1.8, lanzado dos años después en agosto de 2015, Docker en Docker es directamente compatible con Docker de fábrica. Sin embargo, el uso de Docker en Docker viene con una advertencia, aparentemente relacionada con la publicación de Jérôme: ¿Usar Docker-in-Docker para su CI o entorno de prueba? Pensar dos veces. que se centra en las razones por las que Docker en Docker no es una gran opción para la integración continua.

¿Por qué se considera malo usar Docker en Docker? ¿Es simplemente un caso para evitar las tortugas hasta el fondo? o consideraciones de rendimiento?

Preocupaciones de integración continua

En resumen: Docker en Docker (dind) no maneja bien la concurrencia.

La razón por la que no debe usar dind para CI es porque Docker fue diseñado para tener acceso exclusivo al directorio que usa para almacenamiento (normalmente /var/lib/docker). Dind no respeta esto ya que todos los procesos secundarios usan este directorio al mismo tiempo. Cada vez que reconstruye (desde CI, por ejemplo), cualquier cosa relacionada con su aplicación en este directorio podría ser eliminada y forzada a comenzar desde cero. ¿Cómo les gustaría a sus usuarios si ingresaran sus datos de pago, hicieran clic en "Comprar" y de repente volvieran a la pantalla de inicio de sesión como si nunca hubieran hecho nada? Eso no es bueno UX. ¿Dos reconstrucciones ocurren a la vez? Eso realmente va a terminar mal para todos los involucrados (incluida la integridad de sus datos).

Otras preocupaciones

Desde el enlace que publicó el OP, surgen problemas de seguridad ya que el sistema intentará aplicar políticas de seguridad de una manera muy "similar a CSS" en la que un contenedor inferior podría tener acceso a los recursos de un contenedor externo a menos que esté explícitamente prohibido. ¿Recuerda cuándo podía acceder a los recursos del servidor web haciendo algo como "mywebsite.com/../another_folder/private_resource.txt"? Además, a veces los sistemas de archivos simplemente no funcionan bien entre sí cuando están anidados de esta manera.

La solución

Afortunadamente, la publicación del blog en el OP tiene una buena solución para el problema. A menos que sus necesidades no sean satisfechas por "compilar / ejecutar / enviar contenedores Docker desde su propio sistema CI que se ejecuta en Docker", puede usar el -vmodo (agregar un volumen de datos a su contenedor) en el zócalo Docker (generalmente /var/run/docker.sock:/var/run/docker.sock) para permitir el tipo de el acceso que necesita al volumen de datos "compartido". Estos contenedores se iniciarán junto con el padre, en lugar de debajo, forzando la E / S sincrónica. Ahora tiene lo mismo (casi) que dind, pero sin las desventajas que vienen con Docker no creado para la concurrencia.

Referencia (de OP): ¿ Usa Docker-in-Docker para su CI o entorno de prueba? Pensar dos veces.