Combing VOLUME + docker run -v

user_16020611 0
Viewed 1943

I was looking for an explanation on the VOLUME entry when writing a Dockerfile and came across this statement

A volume is a persistent data stored in /var/lib/docker/volumes/...

You can either declare it in a Dockerfile, which means each time a container is started from the image, the volume is created (empty), even if you don't have any -v option.

You can declare it on runtime docker run -v [host-dir:]container-dir. combining the two (VOLUME + docker run -v) means that you can mount the content of a host folder into your volume persisted by the container in /var/lib/docker/volumes/...

docker volume create creates a volume without having to define a Dockerfile and build an image and run a container. It is used to quickly allow other containers to mount said volume.

But I'm having a hard time understanding this line:

...combining the two (VOLUME + docker run -v) means that you can mount the content of a host folder into your volume persisted by the container in /var/lib/docker/volumes/...

For example, let's say I have a config file on my host machine and I run the container based off the image I made with the Dockerfile I wrote. Will it copy the config file into where the volume that I stated in my the volume entry?

Would it be something like (pseudocode)

#dockerfile
From Ubuntu

Run apt-get update

Run apt-get install mysql

Volume . /etc/mysql/conf.d

Cmd systemcl start MySQL

And when I run it

docker run -it -v /path/to/config/file:  ubuntu_based_image

Is this what they mean?

dockerfile docker
1 Answers

  • You probably don't want VOLUME in your Dockerfile. It's not necessary to mount files or directories at runtime, and it has confusing side effects like making subsequent RUN commands silently lose state.

  • If an image does have a VOLUME, and you don't mount anything else there when you start the container, Docker will create an anonymous volume and mount it for you. This can result in space leaks if you don't clean these volumes up.

  • You can use a docker run -v option on any container directory regardless of whether or not it's declared as a VOLUME.

  • If you docker run -v /host/path:/container/path, the two directories are actually the same; nothing is copied, and writes to one are (supposed to be) immediately visible on the other.

  • docker run -v /host/path:/container/path bind mounts aren't visible in /var/lib/docker at all.

  • You shouldn't usually be looking at content in /var/lib/docker (and can't if you're not on a native-Linux host). If you need to access the volume file content directly, use a bind mount rather than a named or anonymous volume.

  • Bind mounts like you've shown are appropriate for injecting config files into containers, and for reading log files back out. Named volumes are appropriate for stateful applications' storage, like the data for a MySQL database. Neither type of volume is appropriate for code or libraries; build these directly into Docker images instead.

user_100081730
Related