Un contenedor Docker en un contenedor Docker usa el daemon Docker del HOST principal y, por lo tanto, cualquier volumen que esté montado en el caso "docker-in-docker" sigue siendo referenciado desde el HOST, y no desde el Contenedor.
Por lo tanto, la ruta real montada desde el contenedor de Jenkins "no existe" en el HOST. Debido a esto, se crea un nuevo directorio en el contenedor "docker-in-docker" que está vacío. Lo mismo se aplica cuando un directorio se monta en un nuevo contenedor Docker dentro de un contenedor.
Algo muy básico y obvio que me perdí, pero me di cuenta tan pronto como escribí la pregunta.
Otra forma de hacerlo es utilizar volúmenes con nombre o contenedores de volúmenes de datos. De esta manera, el contenedor interno no tiene que saber nada sobre el host y tanto el contenedor de Jenkins como el contenedor de compilación hacen referencia al volumen de datos de la misma manera.
He intentado hacer algo similar a lo que estás haciendo, excepto con un agente en lugar de usar el maestro de Jenkins. El problema era el mismo en el sentido de que no podía montar el espacio de trabajo de Jenkins en el contenedor interior. Lo que funcionó para mí fue usar el enfoque del contenedor de volumen de datos y los archivos del espacio de trabajo estaban visibles tanto para el contenedor del agente como para el contenedor interno. Lo que me gustó del enfoque es que ambos contenedores hacen referencia al volumen de datos de la misma manera. Montar directorios con un contenedor interno sería complicado ya que el contenedor interno ahora necesita saber algo sobre el host en el que se ejecuta su contenedor principal.
Tengo una publicación de blog detallada sobre mi enfoque aquí:
http://damnhandy.com/2016/03/06/creating-containerized-build-environments-with-the-jenkins-pipeline-plugin-and-docker-well-casi/
Además del código aquí:
https://github.com/damnhandy/jenkins-pipeline-docker
En mi caso específico, no todo funciona como me gustaría en términos del complemento Jenkins Pipeline. Pero aborda el problema de que el contenedor interno pueda acceder al directorio del espacio de trabajo de Jenkins.
Hay mucha información buena en estas publicaciones, pero creo que ninguna de ellas tiene muy claro a qué contenedor se refieren. Así que vamos a etiquetar los 3 entornos:
- anfitrión:H
- contenedor docker ejecutándose en H:D
- contenedor docker ejecutándose en D:D2
Todos sabemos cómo montar una carpeta de H a D:comience D con
docker run ... -v <path-on-H>:<path-on-D> -v /var/run/docker.sock:/var/run/docker.sock ...
El desafío es:quieres path-on-H estar disponible en D2 como path-on-D2 .
Pero todos fuimos mordidos al intentar montar el mismo path-on-H en D2, porque comenzamos D2 con
docker run ... -v <path-on-D>:<path-on-D2> ...
Cuando comparte el zócalo de la ventana acoplable en H con D, entonces ejecutar los comandos de la ventana acoplable en D es esencialmente ejecutarlos en H. De hecho, si inicia D2 de esta manera, todo funciona (bastante inesperado al principio, pero tiene sentido cuando lo piensa):
docker run ... -v <path-on-H>:<path-on-D2> ...
El siguiente truco es que para muchos de nosotros, path-on-H cambiará dependiendo de quién lo ejecute. Hay muchas formas de pasar datos a D para que sepa qué usar para path-on-H , pero probablemente la más fácil es una variable de entorno. Para aclarar el propósito de tal var, comienzo su nombre con DIND_ . Luego de H empezar D así:
docker run ... -v <path-on-H>:<path-on-D> --env DIND_USER_HOME=$HOME \
--env DIND_SOMETHING=blabla -v /var/run/docker.sock:/var/run/docker.sock ...
y de D inicia D2 así:
docker run ... -v $DIND_USER_HOME:<path-on-D2> ...