Reputation: 3812
I've done a search for site:stackoverflow.com docker: can volume be mounted?
and surely there are a number of posts found about how to do that. However, I'm concerned with IMHO internal contradiction in currently posted on web docker docs (they each do not give you postal date) and ask who knows for sure which is current correct way to say thing and where the docker evolution path leads:
https://docs.docker.com/storage/bind-mounts/:
Bind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes.
https://docs.docker.com/storage/volumes/
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker.
https://docs.docker.com/engine/reference/run/
-v, --volume=[host-src:]container-dest[:]: Bind mount a volume.
Confusion comes from 3rd quote, "bind mount a volume", when two links above it try to separate bind mounts
from volumes
.
Confusion is aggravated by the fact than both --volume
and --mount
parameters to run
can be used for both bind mounts
and volumes
(and tmpfs
btw) and descriptions of their usage include both cases.
What is correct way to say? Are we ok to use mount a volume
or only create volume
?
ADDED:
I've found one "legitimate" usage of mounting a volume: in --volumes-from
flag (to create a new container that mounts that volume), but not for "good-old" --volumes
.
Upvotes: 0
Views: 71
Reputation: 44789
Are we ok to use
mount a volume
or onlycreate volume
?
Well actually both can be used since they are two separate operations. Part of the confusion might also come from the fact that volumes
describes both the source and the target. You create a storage volume in your docker engine and you then mount that volume inside a container.
If the source your provide is a path on your file system, then your are bind-mounting a volume inside your container.
You are focusing on the -v
option of docker run
. What it actually does is:
The --volumes-from
is similar except that volumes will exist since a container is already mounting it/them so they had to be created (or exist in case of a bind mount) at one point
To understand better, see this scenario:
First you manually create a volume.
$ docker volume create testSO
testSO
$ docker volume ls
DRIVER VOLUME NAME
local testSO
Now you can mount that existing storage volume inside a container and push something to it
$ docker run -it --rm -v testSO:/testSO busybox:latest
/ # echo "I'm a test for SO" > /testSO/test.txt
/ # exit
My previous container is now dead and gone but my storage volume is still present. I can remount it on a new container and read the data
$ docker volume ls
DRIVER VOLUME NAME
local testSO
$ docker run -it --rm -v testSO:/testSO ubuntu:18.04
root@d558687a3f6f:/# more /testSO/test.txt
I'm a test for SO
root@d558687a3f6f:/# exit
exit
Now lets delete the storage volume:
$ docker volume rm testSO
testSO
$ docker volume ls
DRIVER VOLUME NAME
If you launch a new container mounting the old volume name, this one will be recreated and mounted all together (but it will be empty of course)
$ docker run -it --rm -v testSO:/testSO busybox:latest
/ # ls /testSO/
/ # exit
$ docker volume ls
DRIVER VOLUME NAME
local testSO
Hope I could help clarify.
Upvotes: 1