Esto sucede porque el volumen está utilizando la private
propagación de montaje. Esto significa que una vez que ocurre la montura, cualquier cambio que ocurra en el lado de origen (por ejemplo, el lado "host" en el caso de Docker) no será visible debajo de la montura.
Hay un par de formas de manejar esto:
Primero monte el NFS, luego inicie el contenedor. La montura se propagará al contenedor, sin embargo, como antes, el contenedor no verá ningún cambio en la montura (incluidos los desmontes).
Utilice la propagación "esclava". Esto significa que una vez que se crea el montaje, cualquier cambio en el lado de origen (host acoplable) podrá verse en el destino (en el contenedor). Si estás haciendo monturas anidadas, querrás usar rslave
( r
para recursivo).
También hay propagación "compartida". Este modo haría cambios en el punto de montaje desde el interior del contenedor propagado al host, así como al revés. Dado que su usuario ni siquiera tendría privilegios para realizar tales cambios (a menos que agregue CAP_SYS_ADMIN), probablemente esto no sea lo que desea.
Puede configurar el modo de propagación al crear el montaje de esta manera:
$ docker run -v /foo:/bar:private
La otra alternativa sería usar un volumen en lugar de un montaje de host. Puedes hacer esto así:
$ docker volume create \
--name mynfs \
--opt type=nfs \
--opt device=:<nfs export path> \
--opt o=addr=<nfs host> \
mynfs
$ docker run -it -v mynfs:/foo alpine sh
Esto asegurará que siempre se monte en el contenedor por usted, no dependa de tener la configuración del host de alguna manera específica o de lidiar con la propagación del montaje.
nota : :
se requiere la parte frontal de la ruta del dispositivo, algo extraño en el módulo del kernel nfs.
nota : Docker actualmente no se resuelve a <nfs host>
partir de un nombre DNS (lo hará en 1.13), por lo que deberá proporcionar la dirección IP aquí.
Más detalles sobre los montajes de "subárbol compartido": https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt