docker-compose volumes not mounting to host directories
I’m using docker-compose for deployment, with a 2
docker-compose.yml setup where I’m building the image locally and pulling from docker hub on the server.
Besides building vs pulling an image, the volumes config is the same.
app: build: . volumes: - "/data/volume:/volume"
And on the server:
app: image: username/repo:tag volumes: - "/data/volume:/volume"
In my Dockerfile:
Locally my volume mounts to the specified directory fine, with files created by the app persisted there outside the container. On the deployment server, however, this does not happen.
Files are however created and persisted through deploys, even though my deployment script runs
docker-compose down -v which presumably removes named & anonymous volumes on the container.
I’m sure I’m doing something wrong, but I can’t see what. Could it be a caching issue? The volume configuration was not the same on initial deploy.
I actually can’t seem to force the images to be lost between deploys. I ran:
docker-compose down -v --rmi all --remove-orphans docker rm $(docker ps -a -q) docker rmi $(docker images -q) docker volume rm $(docker volume ls -q)
… which I thought would leave me with a clean slate for redeploying, then:
docker pull username/repo:tag docker-compose build --no-cache --force-rm docker-compose up -d
… and the files which are supposed to be in the mounted volume are still there, and there’s still nothing in the mounted dir on the disk. Any ideas?
Still more info
docker inspect <container> on the server yields a mount configuration like this:
"Mounts": [ "Source": "/data/volume", "Destination": "/volume", "Mode": "rw", "RW": true, "Propagation": "rprivate" ]
I notice there’s no Driver specified, and not sure about the significance of “rprivate”, but the Source and Destination do appear to be correct.
2 Solutions collect form web for “docker-compose volumes not mounting to host directories”
I suggest on the server check the permissions on /data/volume change them to 777 temporary for testing if this is the issue. Also user server is just a Linux machine? Or is a virtualized environment created with docker-machine or something like that.
The volumes you are using are not anonymous or named but host mounted. There is no command in docker which will delete a host mounted volume.
I also suggest to do the same procedure using
docker run instead
docker-compose to discard a problem with docker-compose
The problem was that I’d mounted a EBS volume to
/volume after the Docker service had been started.
The directory was mounted in the container, which is why the
docker inspect looks correct, but it mounted the pre-existing mount point which was overlayed by the host’s own mount.
This mount happened after the Docker service was started, but long before any containers were actually started up, so it didn’t occur to me that Docker might not be respecting the filesystem change which had happened earlier.
The solution was just to restart the Docker service.