Moving named volume to different location

General
,
1

I was hoping someone could help me to retrace my steps in moving the named volumes to a different location.

Background

I’m running Docker 1.12.6 and Docker Compose 1.12.0 on RHEL 7. The only sudo accesses I was granted are docker and docker-compose.

By the way, the created name volumes resides under Docker root dir… in my case, /var/lib/docker/volumes/.... However, I quickly ran out of space after migrating data from other server into the named volume.

The good news is I was provided a different mount /apps with bigger disk space. Here’s my df -h:-

Filesystem                                      Size  Used Avail Use% Mounted on
/dev/mapper/vg_apps-lv_apps                     197G   10G  177G   6% /apps
/dev/mapper/vg_system-lv_var                    9.8G  2.4G  6.9G  26% /var

The Good News

So, yesterday, for some reason, after reading https://github.com/moby/moby/issues/30441 and spending hours tinkering around, I was able to migrate the named volume from its default location to /apps/docker-volumes/. Here, I have 2 named volumes residing under /apps/docker-volumes/:-

xxx@yyy:/apps/docker-volumes $ ls -la /apps/docker-volumes/
drwxrwxr-x+  5 xxx     xxx     4096 Jun  2 14:15 .
drwxrwxr-x+  7 root    root    4096 Jun  2 09:35 ..
drwxr-xr-x+ 25    1000    1000 4096 Jun  2 14:03 jenkins
drwx------+ 17     200     200 4096 Jun  2 13:53 nexus

To test my sanity, I decided to perform some commands that would add/remove files in these named volumes… and it worked as intended.

The Bad News

Today, I spent the whole day trying to reproduce the steps I did yesterday… but I was unable to get a new named volume created under /apps/docker-volumes/.

So, I created a simplified docker-compose.yml that looks like this:-

version: '2'

services:
  jenkins:
    image: "jenkinsci/jenkins"
    ports:
    - "8080:8080"
    volumes:
     - test:/var/jenkins_home

volumes:
  test:
    driver_opts:
      type: none
      device: /apps/docker-volumes/test
      o: bind

I created /apps/docker-volumes/test:-

xxx@yyy:/apps/docker-volumes $ ls -la /apps/docker-volumes/
drwxrwxr-x+  5 xxx     xxx     4096 Jun  2 14:15 .
drwxrwxr-x+  7 root    root    4096 Jun  2 09:35 ..
drwxr-xr-x+ 25    1000    1000 4096 Jun  2 14:03 jenkins
drwx------+ 17     200     200 4096 Jun  2 13:53 nexus
drwxrwxr-x+  2 xxx         xxx 4096 Jun  2 14:15 test

Before I run the container, I ensured there are no running containers ( sudo docker ps -a ) and there are not same volume names ( sudo docker volume ls ).

Then I tried to run the container, but it failed with this error:-

xxx@yyy:/apps/docker-test $ sudo docker-compose up
Creating volume "dockertest_test" with default driver
Creating dockertest_jenkins_1

ERROR: for jenkins  Cannot create container for service jenkins: no such file or directory
ERROR: Encountered errors while bringing up the project.

I know I missed a few crucial steps in between, but granted I was dead tired yesterday, I just couldn’t recall what else I did different than today.

I truly appreciate it if someone could throw me a pointer or two on how I can fix this problem. It has been very frustrating thus far knowing that I unconsciously solved it yesterday.

Thank you very much for your help in advance.

1 Like
2

Not sure if this is still relevant, but here is one solution I found"

3

I am surprised that a blog-post form 2018 completly ignores that the local drives is able to create volumes baked by a bind out of the box. There is no need to install a docker volume plugin for this.

The compose file example of the OP should have worked as is. Something else must have been wrong. For instance the expectation the volume name would be “test” is not correct for docker-compose deployments, as the project name (which defaults to the directory name) is prefixed to the volume name, followed by an underscore and then the “volume name” inside the compose file.

Local driver means that it is managed localy by the docker engine on the host, regardless wether its a standalone docker engine or one beeing part of a cluster. The same local driver can be used to mount remote cifs and nfs shares - it says nothing about where the data is located.

Just to be clear: for everyone stumbling accross this post, please stick to the local driver with the bind option.

1 Like
4

Thank you for the feedback. You’re completely right so I have updated the post to recommend using the local driver and bind option.