Shulou(Shulou.com)06/01 Report--

This article mainly explains the "Docker directory mount and file sharing method", the article explains the content is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "Docker directory mount and file sharing method"!

Preface

Data in Docker can be stored in media similar to virtual machine disks, called data volumes (Data Volume) in Docker. Data volumes can be used to store data from Docker applications and to share data among Docker containers. The data volume is presented to the Docker container in the form of a directory that supports sharing among multiple containers, and modifications do not affect the image. Data volumes that use Docker are similar to mounting a file system in a system using mount.

Docker file system operation

To understand Docker Volume, we first need to know how Docker's file system works. A Docker image is made up of multiple file systems (read-only layers) superimposed. When we start a container, Docker loads the read-only mirror layer and adds a read-write layer to it (at the top of the mirror stack). If the running container modifies an existing file, the file will be copied from the read-only layer below the read-write layer to the read-write tier, and the read-only version of the file still exists, but has been hidden by a copy of the file in the read-write layer. When you delete the Docker container and restart through the image, the previous changes will be lost. In Docker, the combination of the read-only layer and the read-write layer at the top is called Union File System (federated file system).

In order to preserve (persist) data and share data between containers, Docker proposed the concept of Volume. Simply put, Volume is a directory or file, which can bypass the default federated file system and exist on the host in the form of a normal file or directory.

The most commonly used is actually the use of directory mount and file sharing.

Mount the local directory

When the Docker container starts, if you want to mount a directory of the host, you can specify it with the-v parameter. This also creates a data volume, but mounts the directory of a local host on the container as a data volume.

For example, if I want to start a CentOS container, the / hostTest directory of the host is mounted to the container's / conainterTest directory, which can be specified in the following ways:

1docker run-it-v / hostTest:/conainterTest-- name centos-demo-1 centos

In this way, after the container starts, the directory of / conainterTest is automatically created in the container. In this way, we can make it clear that in the-v parameter, the colon ":" the directory in front is the host directory, and the directory behind is the directory in the container.

Basic operation

Let's verify this: the docker version on my server is 18.09.2.

123 [root@VM_156_200_centos ~] # docker versionClient: Version: 18.09.2

First execute the command:

1234567 [root@VM_156_200_centos /] # docker run-it-v / hostTest:/conainterTest-- name centos-demo-1 centos [root@a8e50a72519e /] # cd conainterTest/ [root@a8e50a72519e conainterTest] # echo "123" > 123 [root@a8e50a72519e conainterTest] # ls123 [root@a8e50a72519e conainterTest] # exitexit

Run A centos image. If it is not available locally, it will perform a docker pull centos download, generate a centos-demo-1 container, and enter interactive mode.

At this point, you can see that there is already a generate / conainterTest directory in the container, and then we create a 123file in this directory and exit the container.

After returning to the host, you can see that the corresponding directory of the host already has the directory / hostTest, and there are 123 files as well.

123456 [root@VM_156_200_centos /] # cd / hostTest/ [root @ VM_156_200_centos hostTest] # ls123 [root @ VM_156_200_centos hostTest] # echo "456" > 456 [root@VM_156_200_centos hostTest] # ls123 456

And we also created a new 456 file to see if it will be synchronized into the container, and then start the container to check:

123456 [root@VM_156_200_centos hostTest] # docker start-ai centos-demo-1 [root@a8e50a72519e /] # cd conainterTest/ [root@a8e50a72519e conainterTest] # ls123 456 [root@a8e50a72519e conainterTest] # cat 456456

You can see that there is this, so the two directories are actually shared. Next, let's analyze several situations of this command in detail.

Container directory cannot be a relative path

The specific instructions are as follows:

123 [root@VM_156_200_centos /] # docker run-it-v / hostTest:conainterTest-- name centos-demo-1 centos docker: Error response from daemon: invalid volume specification:'/ hostTest:conainterTest': invalid mount config for type "bind: invalid mount path: 'conainterTest' mount path must be absolute.See' docker run-help'.

A direct error message indicates that conainterTest is not an absolute path. The so-called absolute path must begin with a slash "/".

If the host directory does not exist, it will be automatically generated

Delete the host directory first: then in the run container:

Ps: because a container is named, but an error will be reported when creating a container with the same name, I have an invisible operation here, that is, each operation will be performed first:

12 [root@VM_156_200_centos /] # docker rm centos-demo-1 centos-demo-1

Of course, this is not the point, so I will not explain this operation again later. By default, every time I run, if the name is the same, then I will delete the container with the same name first.

1234 [root@VM_156_200_centos /] # rm-rf hostTest [root @ VM_156_200_centos /] # docker run-it-v / hostTest:/conainterTest-- name centos-demo-1 centos [root@e57a25c8f8e5 /] # lsanaconda-post.log bin conainterTest dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

Check the host and find that the directory / hostTest has been added.

123 [root@VM_156_200_centos /] # cd hostTest/ [root @ VM_156_200_centos hostTest] # what if the directory of the host is a relative path?

This time, let's try changing the directory name to hostTest1:

1 [root@VM_156_200_centos /] # docker run-it-v hostTest1:/conainterTest-- name centos-demo-1 centos

Next, go to / find out if the hostTest1 directory has been added:

1 [root@VM_156_200_centos /] # ll / | grep 'hostTest1'

Find that you can't find it? So where is the hostTest1 created? We can get the answer to this question by looking at the "Mounts" part of the container through the docker inspect command.

12345678910111213141516171819 [root@VM_156_200_centos hostTest] # docker inspect centos-demo-1 [{... "Mounts": [{"Type": "volume", "Name": "hostTest1", "Source": "/ var/lib/docker/volumes/hostTest1/_data", "Destination": "/ conainterTest", "Driver": "local", "Mode": "z" "RW": true, "Propagation": ""}],...}]

As you can see, the / conainterTest directory in the container mounts the / var/lib/docker/volumes/hostTest1/_data directory on the host.

Originally, the so-called relative path refers to / var/lib/docker/volumes/, which has nothing to do with the current directory of the host.

Is it just the case where-v specifies a directory?

Start a container first:

123 [root@VM_156_200_centos volumes] # docker run-it-v / test2-- name centos-demo-1 centos [root@64e9d535b48c /] # lsanaconda-post.log bin dev etc home lib lib64 media mnt opt proc root run sbin srv sys test2 tmp usr var

It is found that / test2 exists in the container, so where is the host directory? Check it out with docker inspect:

12345678910111213141516171819 [root@VM_156_200_centos hostTest] # docker inspect centos-demo-1 [{... "Mounts": [{"Type": "volume", "Name": "43c602bf16cf87452499988cd4dbfad834e40e2f01e93d960ec01a557f40bc58", "Source": "/ var/lib/docker/volumes/43c602bf16cf87452499988cd4dbfad834e40e2f01e93d960ec01a557f40bc58/_data", "Destination": "/ test2", "Driver": "local", "Mode": " "RW": true, "Propagation": ""}],...}]

As you can see, the result is similar to that in the previous example, except that it is not the directory name of the relative path, but a randomly generated directory name.

If the owner and group of the directory are modified in the container, will the corresponding mount point be changed?

First open a container and check the properties of / conainterTest/ in the container

123 [root@VM_156_200_centos volumes] # docker run-it-v / hostTest:/conainterTest-- name centos-demo-1 centos [root@25d6613bcb81 /] # ll-d / conainterTest/drwxr-xr-x 2 root root 4096 Feb 26 03:24 / conainterTest/

Next, look at the attributes of the / hostTest directory in the host:

12 [root@VM_156_200_centos volumes] # ll-d / hostTest/drwxr-xr-x 2 root root 4096 Feb 26 11:24 / hostTest/

You can see that they are all root. Next, we create a new user in the container and modify the owner and group of / conainterTest:

12345 [root@VM_156_200_centos volumes] # docker start-ai centos-demo-1 [root@25d6613bcb81 /] # useradd kbz [root@25d6613bcb81 /] # chown-R kbz.kbz / conainterTest/ [root@25d6613bcb81 /] # ll-d / conainterTest/drwxr-xr-x 2 kbz kbz 4096 Feb 26 03:24 / conainterTest/

You can see that both the owner and the group have become kbz. Next, check whether the owner and group of the host / hostTest will change?

12 [root@VM_156_200_centos volumes] # ll-d / hostTest/drwxr-xr-x 2 privoxy privoxy 4096 Feb 26 11:24 / hostTest/

Found to have changed, but not a kbz, but a privoxy?

It turns out that this has something to do with UID. UID, that is, the "user identification number", is an integer that is used internally to identify the user. In general, it corresponds to the user name one by one. First, check the UID corresponding to victor in the container:

123 [root@VM_156_200_centos volumes] # docker start-ai centos-demo-1 [root@25d6613bcb81 /] # cat / etc/passwd | grep kbzkbz:x:1000:1000::/home/kbz:/bin/bash

The UID of kbz is 1000, so who is the corresponding user of 1000 in the host?

12 [root@VM_156_200_centos volumes] # cat / etc/passwd | grep 1000privoxy:x:1000:1000::/home/privoxy:/bin/bash

It's really privoxy, so it makes sense.

If the container is destroyed, will the newly created mount directory on the host disappear?

Here, there are two main scenarios to verify:

The host directory is specified, that is,-v / hostTest:/conainterTest.

No host directory specified, i.e.-v / conainterTest

The first is the first case:

123456789 [root@VM_156_200_centos /] # rm-rf / hostTest/ [root@VM_156_200_centos /] # ll | grep hostTest [root @ VM_156_200_centos /] # docker run-it-v / hostTest:/conainterTest-- name centos-demo-1 centos [root@a225da0f4576 /] # exitext [root @ VM_156_200_centos /] # docker rm centos-demo-1 centos-demo-1 [root@VM_156_200_centos /] # ll | Grep hostTestdrwxr-xr-x 2 root root 4096 Feb 26 14:10 hostTest

We first delete the hostTest directory of the host, then mount it, delete the container, and finally find that the hostTest built during mounting still exists.

As you can see, even if the container is destroyed, the newly created mount directory will not disappear. It can also be verified that if the owner and group of the host directory change, after the container is destroyed, the owner and group of the host directory will not return to the state before mounting.

The second situation:

Through the above verification, we know that if the directory of the host is not specified, the container will randomly configure a directory in / var/lib/docker/volumes/. Let's see whether the destruction of the container in this case will result in the deletion of the corresponding directory:

Start the container first:

1 [root@VM_156_200_centos /] # docker run-it-v conainterTest-- name centos-demo-1 centos

Then use docker inspect to view the directory of the mounted host:

12345678910111213141516171819 [root@VM_156_200_centos] # docker inspect centos-demo-1 [{. "Mounts": [{"Type": "volume", "Name": "225e07eb178cc49ee6a4bd95d82430fdf77af717fc4924cb0d201a3f2f162683", "Source": "/ var/lib/docker/volumes/225e07eb178cc49ee6a4bd95d82430fdf77af717fc4924cb0d201a3f2f162683/_data", "Destination": "conainterTest", "Driver": "local", "Mode": " "RW": true, "Propagation": ""}],...}]

Corresponding to / var/lib/docker/volumes/22... 83/_data directory, check to see if this directory exists:

123 [root@VM_156_200_centos /] # ll / var/lib/docker/volumes/225e07eb178cc49ee6a4bd95d82430fdf77af717fc4924cb0d201a3f2f162683/total 4drwxr-xr-x 2 root root 4096 Feb 26 14:14 _ data

It was found that the directory still exists. And even if the docker service is restarted, the directory still exists.

After mounting the existing directory of the host, operate it in the container and report to "Permission denied"

It can be solved in two ways:

Close selinux.

Temporary shutdown: # setenforce 0

Permanently close: modify the / etc/sysconfig/selinux file to set the value of SELINUX to disabled.

Start the container with privilege

Specify the-privileged parameter

1docker run-it-- privileged=true-v / test:/soft centos / bin/bash sets the permissions of the mounted path to read-only

The path permission for mounting defaults to read and write. Available if specified as read-only: ro

1234 [root@VM_156_200_centos /] # docker run-it-v / hostTest:/conainterTest:ro-- name centos-demo-1 centos [root@c9c2a58bbfef /] # cd conainterTest/ [root@c9c2a58bbfef conainterTest] # echo "12" > 12bash: 12: Read-only file system

At this time, if you read and write under the mount directory of the container, an error will be reported.

Mount a file

You can mount not only directories but also files. If the mount directory can be understood as the directory mapping of the system, then mounting files can also be understood as file mapping.

The syntax is similar to mounting a directory. However, it is important to note that when you mount a host file, the file must exist. If the file does not exist, docker will automatically create it for you, as in the above example, but when it is created, it will be a directory, not a file.

Let's try it next:

1234 [root@VM_156_200_centos ~] # vim web.list [root @ VM_156_200_centos ~] # cat web.list11111111112222222222

I created a web.list file and wrote two lines, and then I started mounting the file:

1234567891011 [root@VM_156_200_centos] # docker run-it-v / root/web.list:/root/web.list-- name centos-demo-1 centos [root@6c91b4f6b765 /] # cat / root/web.list 1111111111222222222222 [root@6c91b4f6b765 /] # echo "333333" > > / root/web.list [root@6c91b4f6b765 /] # cat / root/web.list 11111111222222223333 [root@6c91b4f6b765 /] # exitexit

You can see that the mount is successful, and a new line is written in web.list in the container and exits the container

1234567891011 [root@VM_156_200_centos ~] # cat / root/web.list 111111111122222222333333 [root@VM_156_200_centos ~] # echo "444444" > / root/web.list [root@VM_156_200_centos ~] # docker start-ai centos-demo-1 [root@6c91b4f6b765 /] # cat / root/web.list 11111111112222223333444444

You can see that in the host, the new line written by the container has also been synchronized, and then a new line has been added to the host, and then there is also a new line in the container.

Like the above mount directory, the mount file is read-write by default. If it is set to read-only, it cannot be modified in the container. It can only be modified in the host:

123456789101112 [root@VM_156_200_centos] # docker run-it-v / root/web.list:/root/web.list:ro-- name centos-demo-1 centos [root@2a7e3a4ed710 /] # echo "5555" > / root/web.list bash: / root/web.list: Read-only file system [root@2a7e3a4ed710 /] # exitext [root @ VM_156_200_centos ~] # echo "666" > > / root/web.list [root@VM_156_200_centos ~] # cat web.list 11111111112222223333444444666

You can see that editing in the container will report an error, but not in the host.

Mount the data volume container

The above mount directory and mount files are only the way Docker Volume is used.

The way we use it is to create a data volume with the-v parameter followed by the docker run command, and then mount the local directory or file into the container as a data volume. Of course, you can also create multiple data volumes with multiple-v parameters.

So we can create a container of data volumes, which will be used specifically to provide other containers for mounting.

First, create a local directory dedicated to providing data, and then mount it to a common container, which is the data volume container to be mounted by other containers. This method is mainly used to share data among multiple containers.

1234 [root@VM_156_200_centos ~] # mkdir go-data [root@VM_156_200_centos go-data] # cp-r / root/go/src/goworker/. / [root@VM_156_200_centos go-data] # lsgoworker

The go-data directory holds some golang projects, and then we make it into a data volume container and point to the container's / go/src directory:

123456 [root@VM_156_200_centos go-data] # docker run-it-v / root/go-data/:/go/src/-- name centos-go-data centos [root@10d5c4f11e77 /] # cd / go/src [root@10d5c4f11e77 src] # lsgoworker [root@10d5c4f11e77 src] # exitexit

This generates a data volume container called centos-go-data, which contains a go program called goworker in the / go/src directory. I happen to have a mirror image of the go-1.10 environment on my server.

Next, let's run the image, and mount the data volume container centos-go-data (you can mount the data volume container through-volumes-from) to see if there is the go program code in the original / go/src directory that should be empty.

1234567 [root@VM_156_200_centos go-data] # docker run-it-volumes-from centos-go-data-name golang-volume-demo kbz/golang-1.10root@412ab80da79e:/app# cd / go/src root@412ab80da79e:/go/src# lsgoworkerroot@412ab80da79e:/go/src# cd goworker/root@412ab80da79e:/go/src/goworker# lshello_worker.go worker worker.go

You can see that there is a code directory in the src directory that should have been empty, indicating that the data volume has been mounted successfully. Next, add the goworker to a file to see if it will be synchronized to the local directory where it is mounted:

12345678root@412ab80da79e:/go/src/goworker# echo "123" > 123root@412ab80da79e:/go/src/goworker# ls123 hello_worker.go worker worker.goroot@412ab80da79e:/go/src/goworker# exitext [root @ VM_156_200_centos go-data] # cd / root/go-data/goworker/ [root@VM_156_200_centos goworker] # ls123 hello_worker.go worker worker.go

It is found that the local directory also appears the 123 file that just appeared in the container, indicating that the sharing is successful. At this time, we run a container for a new golang environment, and then mount this data volume to see if the data also has this 123file.

1234 [root@VM_156_200_centos goworker] # docker run-it-volumes-from centos-go-data-name golang-volume-demo-2 kbz/golang-1.10root@25d7a8fd5da1:/app# cd / go/src/goworker/root@25d7a8fd5da1:/go/src/goworker# ls123 hello_worker.go worker worker.go

It is found that the new container also has this 123 file.

In fact, most of the time, this kind of data volume container is used for persistence. For example, I have some golang test code to make a data volume container, and then I have several containers in different go environments. Each container will mount this data volume container when it is in run. But we do not want to modify the data in the data volume container in the container of the go environment. Therefore, at the beginning, when we generate this data volume container, we need to set the permission to read-only, so that the data volume becomes a common mount data volume, and other containers can only mount and use the data in it, but cannot modify it:

1234567891011 [root@VM_156_200_centos goworker] # docker rm centos-go-datacentos-go-data [root@VM_156_200_centos goworker] # docker run-it-v / root/go-data/:/go/src/:ro-- name centos-go-datacentos [root@851a09a40cb8 /] # exitext [root @ VM_156_200_centos goworker] # docker run-it-- volumes-from centos-go-data-- name golang-volume-demo-3 kbz/golang-1. 10root@c986955f5ee0:/app# cd / go/src/goworker/root@c986955f5ee0:/go/src/goworker# ls123 hello_worker.go worker worker.goroot@c986955f5ee0:/go/src/goworker# echo "456" > 456bash: 456: Read-only file system

Once modified, an error will be reported.

And this kind of data volume container can be attached to several, just like mounting multiple local directories with-v:

1docker run-- name data-v / opt/data1:/var/www/data1-v / opt/data2:/var/www/data2:ro-it docker.io/ubuntu

A little bit here, there are no-t and-I parameters, so there is no interaction mode after the container is created. Where-I means to run the container in "interactive mode". -t means to open a terminal connected to the container.

12345 [root@VM_156_200_centos js-data] # docker run-it-volumes-from centos-go-data-volumes-from centos-js-data-name golang-volume-demo-4 kbz/golang-1.10root@94e9d5868711:/app# cd / go/src/ & & lsgoworkerroot@94e9d5868711:/go/src# cd / js & & lstest.js

This mounts two data volume containers.

There are two caveats for using data containers:

Don't run the data container, it's a waste of resources.

Don't use "minimal mirroring" for data containers, such as busybox or scratch, just use database mirroring itself. You already have the image, so you don't need to take up any extra space.

Other ways to create data volumes

In addition to creating mount volumes with-v above, docker can also create volumes in the following ways:

Directly use docker volume to manage

The docker volume command is introduced in the new version of Docker to manage Docker volume:

For example, I create a data volume called js-data:

12 [root@VM_156_200_centos js-data] # docker volume create-name js-datajs-data

Now that the creation is successful, you can view the current data volume through docker volume ls:

12345 [root@VM_156_200_centos js-data] # docker volume lsDRIVER VOLUME NAMElocal 0e01f8abe89c9956609eed063c623536112525fb32cf4c0363255a953aa2d35d...local js-data

Then we can use docker volume inspect xxx to see which local directory this data volume corresponds to.

123456789101112 [root@VM_156_200_centos js-data] # docker volume inspect js-data [{"CreatedAt": "2019-02-26T16:12:28+08:00", "Driver": "local", "Labels": {}, "Mountpoint": "/ var/lib/docker/volumes/js-data/_data", "Name": "js-data", "Options": {} "Scope": "local"}]

You can see that the corresponding local directory is the / var/lib/docker/volumes/js-data/_data directory. Of course, at present, this directory is empty:

12 [root@VM_156_200_centos js-data] # ll / var/lib/docker/volumes/js-data/_datatotal 0

You can then mount this data volume:

12345678 [root@VM_156_200_centos js-data] # docker run-it-v js-data:/js-- name golang-volume-demo-3 kbz/golang-1.10root@c55671066dec:/app# cd / jsroot@c55671066dec:/js# lsroot@c55671066dec:/js# echo "123" > 123root@c55671066dec:/js# ls123root@c55671066dec:/js# exitexit

Syntax is not much different, but also-v to specify, but at this time ":" the front is no longer the host directory, but replaced with the js-data data volume, of course, this directory is empty.

Then we added a new file 123 to him to see if the host directory is also available.

12345 [root@VM_156_200_centos js-data] # ll / var/lib/docker/volumes/js-data/_datatotal 4 ll / var/lib/docker/volumes/js-data/_data/123123 RWMurray Rwmuri-1 root root 4 Feb 26 16:29 123 [root@VM_156_200_centos js-data] # cat / var/lib/docker/volumes/js-data/_data/123123

As a matter of fact, there must be. And this method is actually the way in which the host directory is relative to the directory above. In fact, during the docker processing, if the host directory is relative, we will judge whether the volume exists locally, and create one if it does not exist (so we don't need to display it to create a volume). So we can also see that the directory of the Dangdang host was handled relative to the directory in the previous article. At that time, the hostTest1 of the relative directory was already a volume:

123456789101112 [root@VM_156_200_centos js-data] # docker volume inspect hostTest1 [{"CreatedAt": "2019-02-26T11:30:34+08:00", "Driver": "local", "Labels": null, "Mountpoint": "/ var/lib/docker/volumes/hostTest1/_data", "Name": "hostTest1", "Options": null "Scope": "local"}]

But it's important to note that if you want to specify a specific host directory, you can't use this way, ":" the front host directory path still has to use an absolute path.

Create data volumes through dockerfile

In addition to using the docker volume command to display or create data volumes implicitly with the-v host relative to the directory, you can also set volume data volumes in dockerfile.

Ps: note that the data volume container created by [5 Mount data Volume Container] is essentially a container, that is, Docker Container, not Docker Volume. Container can be found in docker ps-a, but not in docker volume ls:

1234 [root@VM_156_200_centos js-data] # docker ps-aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESa559685d18ae centos "/ bin/bash" About an hour ago Exited (0) About an hour ago centos-js-data851a09a40cb8 centos "/ bin/bash" About an hour ago Exited (0) About an hour ago Centos-go-data

Set up the volume data volume in dockerfile, for example:

123456 [root@VM_156_200_centos ~] # mkdir docker-volume-centos [root@VM_156_200_centos ~] # cd docker-volume-centos/ [root@VM_156_200_centos docker-volume-centos] # vim docker [root @ VM_156_200_centos docker-volume-centos] # cat dockerfile FROM centosVOLUME / js-data

You can see that this dockerfile mounts the js-data in a container. Next, build:

1 [root@VM_156_200_centos docker-volume-centos] # docker build-- rm-t volume-centos.

Then run gets up:

12345678 [root@VM_156_200_centos docker-volume-centos] # docker run-it-- name volume-centos-demo volume-centos [root@eeb532993285 /] # cd / js-data [root@eeb532993285 js-data] # ls [root@eeb532993285 js-data] # echo "456" > 456 [root@eeb532993285 js-data] # ls456 [root@eeb532993285 js-data] # exitexit

You can see that after running, there is already a js-data in the container, but this directory is empty, so let's first create a 456 file in this directory. Then exit the container.

Next, let's take a look at the directory of the host corresponding to this shared directory:

12345678910111213141516171819 [root@VM_156_200_centos docker-volume-centos] # docker inspect volume-centos-demo [{... "Mounts": [{"Type": "volume", "Name": "b07ab9cb039ffa90cc0ea7186716aa861cb9bcda11b1925bffca7a6539ee1304", "Source": "/ var/lib/docker/volumes/b07ab9cb039ffa90cc0ea7186716aa861cb9bcda11b1925bffca7a6539ee1304/_data", "Destination": "/ js-data", "Driver": "local", "Mode": " "RW": true, "Propagation": ""}],...}]

You can see that the host directory is this: / var/lib/docker/volumes/b07... 304/_data, let's see if this directory has the file 456:

12345 [root@VM_156_200_centos docker-volume-centos] # ll / var/lib/docker/volumes/b07ab9cb039ffa90cc0ea7186716aa861cb9bcda11b1925bffca7a6539ee1304/_datatotal 4 ll / var/lib/docker/volumes/b07ab9cb039ffa90cc0ea7186716aa861cb9bcda11b1925bffca7a6539ee1304/_data/456 456 [root@VM_156_200_centos docker-volume-centos] # cat / var/lib/docker/volumes/b07ab9cb039ffa90cc0ea7186716aa861cb9bcda11b1925bffca7a6539ee1304/_data/456 456

Yes, there is. You can also set multiple volume through dockerfile, but all of them are relative to the directory, and the file name is random, which is equivalent to the case where only one of the-v is specified above:

1 [root@VM_156_200_centos volumes] # docker run-it-v / test2-- deletion and cleanup of name centos-demo-1 centosVolume

If it belongs to volume, you can delete it by calling docker volume rm xxx directly:

123456 [root@VM_156_200_centos docker-volume-centos] # docker volume lsDRIVER VOLUME NAME...local js-data [root@VM_156_200_centos docker-volume-centos] # docker volume rm js-datajs-data

If it is a mounted data volume container, you can call docker rm xxx to delete it as an ordinary container:

12 [root@VM_156_200_centos docker-volume-centos] # docker rm centos-js-data centos-js-data

Although the container has been deleted, the data of the local directory mounted by the host still exists.

Permissions and licenses for dockerfile volume

This is an interesting phenomenon, that is, if the volume command in dockerfile operates on the shared directory before and after, there will be a difference, for example:

123456 [root@VM_156_200_centos docker-volume-centos] # cat dockerfileFROM centosRUN useradd fooVOLUME / dataRUN touch / data/xRUN chown-R foo:foo / data

This is a dockerfile, and our expected directory is that when run is up, there will be a / data/x file. But in fact, there is no:

1234 [root@VM_156_200_centos docker-volume-centos] # docker build-- rm-t kbz/volume-test. [root@VM_156_200_centos docker-volume-centos] # docker run-it-- name volue-test-demo kbz/volume-test [root@3d037af9a5ca /] # cd / data [root@3d037af9a5ca data] # ls

You can see that although there is a directory called / data, there is no file x in the directory. What's going on with this?

This involves the running rules of dockerfile. Each command in Dockerfile creates a new container to run the specified command and submits the container to the mirror. Each step is built on the previous step.

So in Dockerfile, ENV FOO=bar is equivalent to:

12ciddiesel $(docker run-e FOO=bar) docker commit $cid

So for our example dockerfile, the order of execution should be (the real process may not be like this, but it should be pretty much the same):

12345678 cidental $(docker run centos useradd foo) image_id=$ (docker commit $cid) cid=$ (docker run-v / data centos) image_id=$ (docker commit $cid) cid=$ (docker run $image_id touch / data/x) image_id=$ (docker commit $cid) cid=$ (docker run $image_id chown-R foo:foo / data) docker commit $(cid) volue-test-demo

Then this process is obvious, because each line launches a new container, so every time there is a new volume, that is, every time the run's new container, / data is new.

So in fact, our touch operation is operated in the data directory of the current volume, not in the actual container or mirrored file system. So when we re-run, the new volume is an empty data directory.

So if you want to change it, you should first store the operation of the touch in the mirrored file system, and then mount it in the mount directory:

1234567 [root@VM_156_200_centos docker-volume-centos] # vim docker [root @ VM_156_200_centos docker-volume-centos] # cat dockerfile FROM centosRUN useradd fooRUN touch / data/xRUN chown-R foo:foo / dataVOLUME / data

This is the modified dockerfile.

12345 [root@VM_156_200_centos docker-volume-centos] # docker build-- rm-t kbz/volume-test-2. [root@VM_156_200_centos docker-volume-centos] # docker run-it-- name volue-test-demo-2 kbz/volume-test-2 [root@2850978389ac /] # cd / data [root@2850978389ac data] # lsx

At this point, there will be an x file. And the corresponding host directory also has this x file:

123 [root@VM_156_200_centos docker-volume-centos] # cd / var/lib/docker/volumes/d4c83377d137104a13893b31e42c57e3635e8e59c14027463361b814c86c6ad7/_ data [root @ VM_156_200_centos _ data] # lsx thank you for reading. This is the content of "Docker directory mount and file sharing method". After the study of this article, I believe you have a deeper understanding of the method of Docker directory mount and file sharing. The specific use situation still needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.