How to dynamically add a volume to a running Docker container

Someone asked me before whether it is possible to mount volumes after the Docker container has been started. Considering how the mnt namespace works, I initially thought this would be difficult to achieve. But now I think it has been achieved.

• In short, to mount a disk volume to a running container, we need to:
• Use nsenter to mount the entire file system containing this disk volume to a temporary mount point;
• Create a bind mount from the specific folder we want to use as a disk volume to the location of this disk volume;

Umount the temporary mount point created in the first step.

Precautions

In the following examples, I intentionally included the $ sign to indicate that this is a shell command line prompt to help you distinguish what you need to enter and what the machine replies. For some multi-line commands, I continue to use >. I realize this makes the commands in the examples not easily copy-pastable. If you want to copy and paste the code, check out the example script at the end of the article.

Detailed steps

The following examples assume that you have started a simple container named charlie using the following command:

$ docker run --name charlie -ti ubuntu bash

What we need to do is mount the host folder /home/jpetazzo/Work/DOCKER/docker to the /src directory in the container. Okay, let's get started.

nsenter

First, we need nsenter and the docker-enter helper script. Why? Because we want to mount the file system from the container. Due to security considerations, the container does not allow us to do this. Using nsenter, we can break through the above security restrictions and run arbitrary commands in the context of the container (strictly speaking, the namespace). Of course, this requires root privileges on the Docker host.

The simplest way to install nsenter is to run it in conjunction with the docker-enter script:

$ docker run --rm -v /usr/local/bin:/target jpetazzo/nsenter

For more details, see the nsenter project homepage.

Find the file system

We want to mount the file system containing the host folder (/home/jpetazzo/Work/DOCKER/docker) in the container. Then we need to find out which file system contains this directory.

First, we need to canonicalize (or dereference) the file in case it is a symbolic link, or its path contains symbolic links:

$ readlink --canonicalize /home/jpetazzo/Work/DOCKER/docker
/home/jpetazzo/go/src/github.com/docker/docker

Ha, it is indeed a symbolic link! Let's put this into an environment variable:

$ HOSTPATH=/home/jpetazzo/Work/DOCKER/docker
$REALPATH=$(readlink --canonicalize $HOSTPATH)

Next, we need to find out which filesystem contains this path. We do this using a somewhat unexpected tool: df:

$ df $REALPATH
Filesystem 1K-blocks Used Available Use% Mounted on
/sda2 245115308 156692700 86157700 65% /home/jpetazzo

Use the -P flag (to force POSIX format, in case you have an exotic df, or someone else's df when installing Docker on Solaris or BSD), and put the result into a variable as well:

$ FILESYS=$(df -P $REALPATH | tail -n 1 | awk '{print $6}')

Find the device (and sub-root) of the file system

Now, there are no bind mounts or BTRFS subvolumes on the system, we just need to look in /proc/mounts and find the device corresponding to the /home/jpetazzo file system. But in my system, /home/jpetazzo is a subvolume of the BTRFS pool. To get the subvolume information (or bind mount information), you need to check /proc/self/moutinfo.

If you've never heard of mountinfo, check out the kernel documentation for proc.txt.

First, get the file system device information:

$ while read DEV MOUNT JUNK
> do [ $MOUNT = $FILESYS ] && break
> done </proc/mounts
$ echo $DEV
/dev/sda2

Next, get the sub-root information (i.e. the path to the mounted file system):

$ while read ABC SUBROOT MOUNT JUNK
> do [ $MOUNT = $FILESYS ] && break
> done < /proc/self/mountinfo 
$ echo $SUBROOT
/jpetazzo

very good. Now we know we need to mount /dev/sda2 . Inside the file system, go to /jpetazzo, from here you can get the rest of the path to the required file ( /go/src/github.com/docker/docker in this example).
Let's calculate the remaining path:

$ SUBPATH=$(echo $REALPATH | sed s,^$FILESYS,,)

Note: This method only works if there is no "," in the path. If you have a "," in your path and want to mount the directory using the method in this article, please let me know. (I need to invoke the Shell Triad to solve this problem: jessie, soulshake, tianon?)

The last thing to do before entering the container is to find the major and minor numbers of the block device. You can use stat:

$ stat --format "%t %T" $DEV
8 2

Note that these two numbers are in hexadecimal, we will need binary later. This can be converted like this:

$ DEVDEC=$(printf "%d %d" $(stat --format "0x%t 0x%T" $DEV))

Summarize

There is one last step. For some reason I can't explain, some filesystems (including BTRFS) update the device field in /proc/mounts after being mounted multiple times. That is, if we create a temporary block device called /tmpblkdev in the container and use it to mount our own filesystem, the filesystem will appear (on the host machine!) as /tmpblkdev, not /dev/sda2. This may sound harmless, but in practice it will cause subsequent attempts to get the file system block device to fail.

Long story short, we want to make sure that the block device nodes in the container are located at the same path as on the host machine.

You need to do this:

$ docker-enter charlie --sh -c \
> "[ -b $DEV ] || mknod --mode 0600 $DEV b $DEVDEC"

Create a temporary mount point to mount the file system:

$ docker-enter charlie --mkdir /tmpmnt
$ docker-enter charlie --mount $DEV /tmpmnt

Make sure the volume mount point exists and bind mount the volume:

$ docker-enter charlie --mkdir -p /src
$ docker-enter charlie --mount -o bind /tmpmnt/$SUBROOT/$SUBPATH /src

Delete the temporary mount point:

$ docker-enter charlie --umount /tmpmnt
$ docker-enter charlie --rmdir /tmpmnt

(We don't clear the device node. It might be redundant to check if the device exists in the first place, but it's already complicated enough.)

Mission accomplished!

Automate everything

The following paragraph can be copied and pasted directly.

#!/bin/sh
set -e
CONTAINER=charlie
HOSTPATH=/home/jpetazzo/Work/DOCKER/docker
CONTPATH=/src

REALPATH=$(readlink --canonicalize $HOSTPATH)
FILESYS=$(df -P $REALPATH | tail -n 1 | awk '{print $6}')

while read DEV MOUNT JUNK
do [ $MOUNT = $FILESYS ] && break 
done </proc/mounts
[ $MOUNT = $FILESYS ] # Sanity check!

\while read ABC SUBROOT MOUNT JUNK
\do [ $MOUNT = $FILESYS ] && break
\done < /proc/self/mountinfo 
[ $MOUNT = $FILESYS ] # Mount sanity check!

SUBPATH=$(echo $REALPATH | sed s,^$FILESYS,,)
DEVDEC=$(printf "%d %d" $(stat --format "0x%t 0x%T" $DEV))

docker-enter $CONTAINER -- sh -c \
   "[ -b $DEV ] || mknod --mode 0600 $DEV b $DEVDEC"
docker-enter $CONTAINER --mkdir /tmpmnt
docker-enter $CONTAINER --mount $DEV /tmpmnt
docker-enter $CONTAINER --mkdir -p $CONTPATH
docker-enter $CONTAINER --mount -o bind /tmpmnt/$SUBROOT/$SUBPATH $CONTPATH
docker-enter $CONTAINER --umount /tmpmnt
docker-enter $CONTAINER --rmdir /tmpmnt

Status and limitations

The above method does not apply to file systems that are not based on block devices. It only works when /proc/mounts can correctly obtain the block device node (as mentioned above, it is not always possible to obtain it correctly). Also, I've only tested this in my own environment, not in a cloud instance or something, but I'd be interested to see if it holds true there.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.