Tengo un contenedor que contiene la lógica para coordinar la implementación de los microservicios en el host; llamemos a este servicio el implementador . Para lograrlo, monté el archivo /var/run/docker.sock del host en ese contenedor de implementación .
Por lo tanto, cuando ejecuta docker run hello-world desde el contenedor del implementador , el host lo ejecuta. Este sistema funciona como se esperaba, excepto por una cosa de la que no estoy seguro ahora, ya que he visto un comportamiento inesperado.
Al ejecutar docker run -v "/path/to/src:/path/to/dest" hello-world , ¿qué carpeta mirará Docker? Estoy viendo dos razonamientos válidos:
/path/to/src desde dentro del programa de implementación al contenedor hello-world, ya que ese es el shell que ejecuta el comando./path/to/src desde el origen hasta el contenedor hello-world, ya que docker.sock determina el contexto y el comando se ejecuta en el host. ¿Cuál de esos es correcto?
Además, al usar rutas relativas (por ejemplo, en docker-compose), ¿cuál será la ruta que se está utilizando?
Siempre usará el sistema de archivos host. No hay forma de montar directamente el sistema de archivos de un contenedor en otro.
Por ejemplo:
host$ sudo docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker sh 0123456789ab# docker run -v /:/host --rm -it busybox sh 13579bdf0246# cat /host/etc/shadowEl último comando imprimirá el archivo de contraseña cifrada del host, no nada en el contenedor intermedio.
Si no es obvio a partir del ejemplo, montar el socket de Docker para ejecutar comandos de Docker mediante programación tiene enormes implicaciones de seguridad, y debe considerar detenidamente si realmente es un buen enfoque para usted.
Estoy bastante seguro de que las rutas relativas en docker-compose.yml en realidad no funcionarán con esta configuración (porque no se pueden vincular y montar cosas fuera del contenedor intermedio). Tendría que montar el mismo contenido en ambos contenedores para que uno pueda enviar archivos al otro. El uso de volúmenes con nombre puede ser útil aquí (porque los nombres de los volúmenes en realidad no dependen de las rutas del host); dependiendo de lo que esté haciendo exactamente, podría funcionar una ruta indirecta de docker create y luego docker cp .
A nivel de implementación, solo hay un demonio Docker y se ejecuta en el host. Puede publicar su socket en varios lugares, pero en última instancia, ese demonio recibe solicitudes como "crear un contenedor que monte el directorio de host /x/y" y el demonio interpreta esas solicitudes en el contexto del host. No sabe que una solicitud provino de un contenedor diferente (o, potencialmente, de un host diferente; pero consulte más arriba sobre cuestiones de seguridad).