I think #2 and #3 are pretty much the same thing, the main difference is that there is no stopped container with #3 (it is literally, just a named volume). For example, you can create a named volume and do similarly what you would do with #2 with -v
instead.
Create a named volume:
$ docker volume create --name test
Mount and write some data to that volume from a container:
$ docker run -v test:/opt/test alpine touch /opt/test/hello
You can then mount that same test
volume in another container and read the data:
$ docker run -v test:/opt/test alpine ls -al /opt/test
total 8
drwxr-xr-x 2 root root 4096 Jan 23 22:28 .
drwxr-xr-x 3 root root 4096 Jan 23 22:29 ..
-rw-r--r-- 1 root root 0 Jan 23 22:28 hello
The advantage here is that the volume won't accidentally disappear if you remove the data-only container. You now manage it with the docker volume
sub-command.
$ d volume ls
DRIVER VOLUME NAME
local test
It also opens the possibilities for volume drivers down the road so you might be able to do shared volumes between hosts (ie. named volumes over NFS). Examples of this might be Flocker and Convoy. To your point specifically about moving or backing up data, Convoy has specific sub-commands for backing up data and allows for storage on NFS or EBS external to your host.
For this reason, I think the more new-school way (Docker 1.9+) is to use a named volume rather than a data-only container.
Purpose of the volumes
key
It is there to create named volumes.
If you do not use it, then you will find yourself with a bunch of hashed values for your volumes. Example:
$ docker volume ls
DRIVER VOLUME NAME
local f004b95d8a3ae11e9b871074e9415e24d536742abfe86b32ffc867f7b7063e55
local 9a148e167e1c722cbdb67c8edc36f02f39caeb2d276e9316e64de36e7bc2c35d
With named volumes, you get something like the following:
$ docker volume ls
local projectname_someconf
local projectname_otherconf
How to create named volumes
The docker-compose.yml
syntax is:
version: '2'
services:
app:
container_name: app
volumes_from:
- appconf
appconf:
container_name: appconf
volumes:
- ./Docker/AppConf:/var/www/conf
volumes:
appconf:
networks:
front:
driver: bridge
This something like above shown named volumes.
How to remove volumes in bulk
When you have a bunch of hashes, it can be quite hard to clean up. Here's a one-liner:
docker volume rm $(docker volume ls |awk '{print $2}')
Edit: As @ArthurTacca pointed out in the comments, there's an easier to remember way:
docker volume rm $(docker volume ls -q)
How to get details about a named volume
Now that you do not have to look up hashes anymore, you can go on it and call them by their … name:
docker volume inspect <volume_name>
# Example:
$ docker volume inspect projectname_appconf
[
{
"Name": "projectname_appconf",
"Driver": "local",
"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/projectname_appconf/_data"
}
]
Sidenote: You might want to docker-compose down
your services to get a fresh start before going to create volumes.
In case you are using Boot2Docker/ Docker Machine, you will have to docker-machine ssh
and sudo -i
before doing a ls -la /mnt/…
of that volume – you host machine is the VM provisioned by Docker Machine.
EDIT: Another related answer about named volumes on SO.
Best Answer
You cannot currently rename existing volumes. (This is true whether they were previously named or were unnamed and had their names auto-generated.)
You can see this issue for more information on implementation of this feature, as well as add your "+1"/"Thumbs up" to let the developers know that you want it.
Without that, as far as I know, the only good way to do it is to create the new named volume and copy the data.