Understand the Volumes in Docker

This is a creation in Article, where the information may have evolved or changed.

Understand the Volumes in Docker

Why

This article translates from understanding Volumes in Docker, like the original author, when I first approached Docker, I was somewhat puzzled by the concept of Volumes in Docker,Docker run-it-v/some/dir : does the- v option in/another/dir Someimage:sometag achieve the same effect as the VOLUME defined in Dockerfile? After reading this article only suddenly enlightened, so translated to consolidate understanding on the one hand, share on the other.

President

From the Docker IRC channel (Ross: Using the Docker IRC channel mentioned here, and by the way the chat rooms on Python and C + +, there is a group of people on the network with the old chat room, Lenovo to the card house mentioned deep Web, sure enough What we can see on the internet is just the tip of the iceberg) and StackOverflow often see the problem can be clearly seen, many people Volumes in Docker How to work is very confused. In this article, I'll explain how Volumes works and uses some of its best practice. While this article is targeted at people who have little knowledge of Docker, the practice of Docker is likely to learn something from it, because this article discusses some of the topics that many people don't know about Volumes.

To understand what Volume is in Docker, we first need to figure out how Docker's file system works. The Image of Docker is stored in a series of Layers. When we start a Container, Docker adds a read-write layer to the upper layer of the ReadOnly Image. When a running Container modifies an existing file, the file is copied to the top-level read-write layer in a read-only layer and modified to save, so that the version in the read-write layer hides the affected file in the ReadOnly layer, rather than deleting the original file. The original file will always exist in the original Image. When this Docker Container is deleted, re-using this Image to create a new Container will lose all the changes made in the previous Container. In summary, Docker adds a new, read-write layer to the top of the Union File System when the caller has a series of read-only Layers.

To be able to save or persist data and share it among different Containers, Docker puts forward the concept of Volumes. Very simply, Volumes is a normal folder or file that is independent of the default Union file system and exists in the host filesystem.

There are two ways to create Volumes, both of which are slightly different and need to be treated with care. We can declare a Volume when we create a new Container:

Doing so uses the/data directory in the Container container to exist independently of the Union File system and can be accessed by the host. All the files in the/data directory in this Image will be copied to this Volume, and we can get the specific path of this Volume on the host by executing the Docker inspect command on the host. Open a new command-line window and leave the current Container in the running state and enter the following command:

$ docker inspect -f  container-test

We will see information similar to the following:

This means that Docker will mount a folder in the/var/lib/docker directory as a/data directory in this Container. Now let's put a file in this directory from host:

$ sudo touch /var/lib/docker/vfs/dir/cde167197ccc3e138a14f1a4f7c0d65b32cecbada822b0db4cc92e79059437a9/test-file

Then go back to the Container we created earlier and look at the/data directory:

$ root@CONTAINER:/# ls /datatest-file

The above modification takes effect immediately, because the/data directory in Container is the mount of the directory on the host.

We can achieve the same effect by defining the VOLUME tag in Dockerfile:

FROM debian:wheezyVOLUME /data

But there's a difference between using the- v parameter here and when creating the Docker Container, specifically, the __-v__ parameter can do it, but Docker VOLUME can't do it: we can mount a specific directory above the host to Cont Ainer:

$ docker run -v /home/adrian/data:/data debian ls /data

This command will mount the/home/adrian/data directory above host as the Container/data directory. All files and folders that already exist in the/home/adrian/data can be accessed immediately in Container. This is useful when host and Container are required to share data. For example, mount the source code directory to Container for compilation. The directory used for Volumes in host cannot be defined in Dockerfile for portability, as there is no guarantee that all hosts will have the same directory. When the- v parameter is used, the contents of any attached directory in the Image will not be copied to this VOLUME.

Sharing data

To enable one Container to access the data in another Container, we can use the –volumes-from parameter when executing the Docker run command:

$ docker run -it -h NEWCONTAINER --volumes-from container-test debian /bin/bashroot@NEWCONTAINER:/# ls /datatest-fileroot@NEWCONTAINER:/#

It is important to note that whether container-test this container is running or not. It is not deleted when a Volume has Container connected to it.

Data container

Using a data-only Container to persist databases, configuration files, and data files has become a common practice. Docker website has some good documentation to discuss this topic. For example:

$ docker run --name dbdata postgres echo "Data-only container for postgres"

This command creates a Postgres Container that contains the Volume defined in Dockerfile, executes the echo command, and exits. Here the echo command is useful for helping us understand the purpose of Container. We can use the Volume defined here when creating another Container:

$ docker run -d --volumes-from dbdata --name db1 postgres

There are two points to pay special attention to when working with data containers:

• There is no need to keep the data container running, it is a waste of resources to run it.
• Do not use busybox or scratch these minimum Images for the data container, that is, the database Image itself is good. Now that we have downloaded the database Image, building a Container does not add more resource usage, and Volumes can also be used to get some data from the image's Mount directory.

Permissions and owners

Very often, we will need to have permission and owner control over a Volume, which puts in some default data or configuration files when initializing Volume. The key point is to recognize that any changes to the Mount directory will not take effect after all VOLUME tags, such as:

FROM debian:wheezyRUN useradd fooVOLUME /dataRUN touch /data/xRUN chown -R foo:foo /data

The Dockerfile will not work according to our expectations. We expect the result of the touch command to be stored in the file system of Image, but in fact it is only executed in a temporary Container and will not be saved. The following wording is correct:

FROM debian:wheezyRUN useradd fooRUN mkdir /data && touch /data/xRUN chown -R foo:foo /dataVOLUME /data

Docker will intelligently copy everything from the Image in the attached directory to the Volume below and give the appropriate permissions and owners. When we use the- v parameter to mount a directory above the host to Container, the copy does not occur to prevent the contents of the host from being overwritten by the contents of the Image.

Although we cannot use the run command to set permissions and owners, we can use CMD or entrypoint to run scripts to do these things after Container is created.

Delete Volumes

Unlike many of the expectations, when we use Docker rm to remove Containers, we may not remove these Containers associated Volumes.

Volumes will only be removed if the following is the case:

• Container is removed with the Docker rm-v command and there is no other Containers associated with this Volume, there is no directory on the host and this Volume association, and-v is required here.
• The -rm parameter and Docker run are a pair.

We have to follow the above rules for Containers management, otherwise the time will be/var/lib/docker/vfs/dir under the production of a lot of junk files, and can not tell which could be safely deleted.

More information

The following resources provide a more in-depth discussion of this topic and are a reference for this writing:

• Data-only Container Madness
• Docker In-depth:volumes
• Managing Data in Containers

Finally, with regard to managing Volumes, we have many tools to choose from: Proposal #8484

Disclaimer: The English copyright of the translation of this article belongs to the original author, please specify the source.

--EOF--

• Ubuntu 14.04 system based on Gunicorn and Nginx deployment Flask application →
• ←dockerfile Best Practices

Disclaimer: This article uses the BY-NC-SA protocol to authorize. Reprint please specify turn from: Understand Volumes in Docker