CODEWITHSUNDEEP
dockerdockerfile
Nag
Nag

Reputation: 2057

Dockerfile VOLUME command, data is lost when mounted as bindmount

I created a Dockerfile and ran the container with bindMount, the contents are lost ( no content)

FROM alpine:3.8
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

docker run -it --name volDemo2 -v $(pwd)/myvol:/myvol voldemo sh

I am expecting the "myvol" under "pwd" should contain "greeting", which is not the case

  root@default:/home/docker# docker run -it --name volDemo2 -v $(pwd)/myvol:/myvol voldemo sh           
/ # cd myvol/                                                                                         
/myvol # ls                                                                                           
/myvol #

However, the same works fine if it is mounted the following way

docker@default:~$ docker run -it --name volDemo1 -v myvol:/myvol voldemo sh  
/ # cd myvol/                                                                
/myvol # ls                                                                  
1.txt     greeting                                                           
/myvol # exit

Is it the expected behavior, VOLUME instruction will work only with "volume" and not "bindmounts"

Upvotes: 0

Views: 231

Answers (1)

BMitch
BMitch

Reputation: 265006

This is how bind mounts work. They mount one folder in another path on the filesystem. All access to the target path get mapped directly back to the source directory.

What docker provides for a named volume (your second example) is an initialization step when that named volume is empty on container creation. They will copy all files, directories, and metadata like file owner and permissions, from the image filesystem into the named volume before the container is started. This only happens with named volumes and not host mounts or tmpfs volumes. And this only happens when the named volume is empty, so it will not updated as you change the image.

You can make a named volume that mounts other directories on the host by passing additional options, giving you something between a host mount and default named volume, since they are both implemented with a bind mount. Three different examples of that are shown below:

  # create the volume in advance
  $ docker volume create --driver local \
      --opt type=none \
      --opt device=/home/user/test \
      --opt o=bind \
      test_vol

  # create on the fly with --mount
  $ docker run -it --rm \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=none,volume-opt=o=bind,volume-opt=device=/home/user/test \
    foo

  # inside a docker-compose file
  ...
  volumes:
    bind-test:
      driver: local
      driver_opts:
        type: none
        o: bind
        device: /home/user/test
  ...

If your goal is to keep things simple for other users of the image, and potentially update the volume with new versions of the image, then you'll want to do this as part of your entrypoint script. I do this in my volume caching scripts included in my base image. You copy the volume directory to a safe location inside the image, and then on container startup, the entrypoint script will copy the files into the volume.

Upvotes: 1

Related Questions