Detailed explanation of Docker Volume permission management

Volume data volume is an important concept of Docker. Data volumes are special directories that can be used by one or more containers and provide valuable features for container application storage:

• Persistent data is decoupled from the container lifecycle: the content in the data volume can be retained after the container is deleted. The named volume introduced after Docker 1.9 can more conveniently manage the life cycle of data volumes; data volumes can be created and deleted independently.
• Data volumes can be used to share data between containers
• Can support different types of data storage implementations

Docker provides support for local file volumes on the host by default, and can mount the host's directory into the container. Since there is no performance loss caused by the container layered file system, local file volumes are very suitable for scenarios that require high-performance data access, such as the storage of MySQL database files. At the same time, Docker supports different types of data volumes through volume plugins, which can more flexibly solve the storage requirements of different application loads. For example, Alibaba Cloud Container Service can provide containers with cloud disk-based block storage and OSSFS and NAS/NFS-based shared file storage.

However, managing permissions on Docker volumes is often very confusing. This article will introduce common problems and solutions in Docker data volume permission management with examples.

Talking about the error of mounting local data volume from Jenkins

A colleague recently encountered a problem when running Jenkins in a container. The steps to reproduce it are as follows:

Note: If you are using Windows/Mac, you need to log in to the Boot2docker virtual machine, but this is not necessary for Linux.

docker-machine ssh default

Start the Jenkins official image and check the log

docker run -d -p 8080:8080 -p 50000:50000 --name jenkins jenkins
docker logs jenkins

We can find that the "jenkins" container log shows that everything is normal

However, in order to persist the Jenkins configuration data, when we mount the data folder in the current directory of the host to the directory "/var/jenkins_home" in the container, a problem arises:

docker rm -f jenkins
docker run -d -p 8080:8080 -p 50000:50000 -v $(pwd)/data:/var/jenkins_home --name jenkins jenkins
docker logs jenkins

The error log is as follows

touch: cannot touch '/var/jenkins_home/copy_reference_file.log': Permission denied
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?

What is going on?

Let's check the permissions of the "/var/jenkins_home" directory in the previous startup method and check the current user of the Jenkins container: the current user is "jenkins" and the "/var/jenkins_home" directory is owned by the jenkins user

docker@default:~$ docker run -ti --rm --entrypoint="/bin/bash" jenkins -c "whoami && id"
Jenkins
uid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)

docker@default:~$ docker run -ti --rm --entrypoint="/bin/bash" jenkins -c "ls -la /var/jenkins_home"
total 20
drwxr-xr-x 2 jenkins jenkins 4096 Jun 5 08:39 .
drwxr-xr-x 28 root root 4096 May 24 16:43 ..
-rw-r--r-- 1 jenkins jenkins 220 Nov 12 2014 .bash_logout
-rw-r--r-- 1 jenkins jenkins 3515 Nov 12 2014 .bashrc
-rw-r--r-- 1 jenkins jenkins 675 Nov 12 2014 .profile

When mapping a local data volume, the owner of the /var/jenkins_home directory becomes the root user

docker run -ti --rm -v $(pwd)/data:/var/jenkins_home --entrypoint="/bin/bash" jenkins -c "ls -la /var/jenkins_home"
total 4
drwxr-sr-x 2 root staff 40 Jun 5 08:32 .
drwxr-xr-x 28 root root 4096 May 24 16:43 ..

This explains why when the "jenkins" user's process accesses the "/var/jenkins_home" directory, a Permission denied problem occurs.

Let's check the data volume directory on the host machine again. The owner of the "data" directory under the current path is "root". This is because this directory is created by default by the Docker process.

docker@default:~$ ls -la data
total 0
drwxr-sr-x 2 root staff 40 Jun 5 08:32 ./
drwxr-sr-x 5 docker staff 160 Jun 5 08:32 ../

After discovering the problem, the corresponding solution is also very simple: assign the owner of the current directory to uid 1000, and then start the "jenkins" container and everything will be normal.

sudo chown -R 1000 data
docker start jenkins

At this time, use the browser to access "http://192.168.99.100:8080/" to see the Jenkins web interface. Note: If you cannot access it, you may need to use the docker-machine ip command to obtain the IP address of the current Docker host.

When we enter the container again to check the permissions of the "/var/jenkins_home" directory, its owner has become "jenkins"

docker@default:~$ docker exec jenkins ls -la /var/jenkins_home
total 24
drwxr-sr-x 11 jenkins staff 340 Jun 5 09:00 .
drwxr-xr-x 28 root root 4096 May 24 16:43 ..
drwxr-sr-x 3 jenkins staff 60 Jun 5 08:59 .java
-rw-r--r-- 1 jenkins staff 289 Jun 5 08:59 copy_reference_file.log
...

What’s interesting is that the owner of the “data” directory we see on the host is “docker”. This is because the uid of the “docker” user on the “boot2docker” host is also “1000”.

docker@default:~$ ls -la data
total 20
drwxr-sr-x 2 docker staff 40 Jun 5 11:55 ./
drwxr-sr-x 6 docker staff 180 Jun 5 11:55 ../
...

At this point we already know that the permissions of files/directories in the container's local data volume are consistent with those on the host, except that uid/gid may be mapped to different user/group names in the Docker container and the host.

In the above, we used a common trick, that is, using uid instead of a specific username when executing the chown command on the host machine, so that the correct owner can be set.

Although the problem has been solved, the thinking is not over. Because when using local data volumes, the Jenkins container relies on the correctness of the host directory permissions, which adds extra work to automated deployment. Is there a way to have the Jenkins container automatically set the correct permissions for the data volume? This problem is also instructive for many applications that run in non-root mode.

Correctly mount local data volumes for non-root applications

We can find many related discussions on the almighty stackoverflow.com. One of the most instructive questions and answers is as follows:

http://stackoverflow.com/questions/23544282/what-is-the-best-way-to-manage-permissions-for-docker-shared-volumes

There are two basic ideas:

One is to use the Data Container method to share data volumes between containers. This avoids the need to resolve permissions issues on the data volume on the host machine. Since Docker provides named volumes to replace pure data containers after version 1.9, we still need to really solve this problem.

Another idea is to start the container as the root user, use the "chown" command in the container startup script to modify the data volume file permissions, and then switch to the non-root user to execute the program.

Let's refer to the second idea to solve this problem.

Below is a Dockerfile based on the Jenkins image: it switches to the "root" user and adds the "gosu" command to the image, and a new entry point "/entrypoint.sh"

FROM jenkins:latest
USER root
RUN GOSU_SHA=5ec5d23079e94aea5f7ed92ee8a1a34bbf64c2d4053dadf383992908a2f9dc8a \
 && curl -sSL -o /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/1.9/gosu-$(dpkg --print-architecture)" \
 && chmod +x /usr/local/bin/gosu \
 && echo "$GOSU_SHA /usr/local/bin/gosu" | sha256sum -c - 
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Note: gosu is a small tool that often appears in official Docker images. It is a lightweight replacement for the "su" and "sudo" commands and solves some of their problems with tty and signal delivery.

The content of the new entry point "entrypoint.sh" is as follows: it will set the ownership of "jenkins" for the "JENKINS_HOME" directory, and then use the "gosu" command to switch to the "jenkins" user to execute the "jenkins" application.

#!/bin/bash
set -e
chown -R 1000 "$JENKINS_HOME"
exec gosu jenkins /bin/tini -- /usr/local/bin/jenkins.sh

You can get the relevant code directly from https://github.com/denverdino/docker-jenkins and build your own Jenkins image. The execution command is as follows:

git clone https://github.com/AliyunContainerService/docker-jenkins
cd docker-jenkins/jenkins
docker build -t denverdino/jenkins .

Then start the Jenkins container based on the new image

docker rm -f jenkins
docker run -d -p 8080:8080 -p 50000:50000 -v $(pwd)/data:/var/jenkins_home --name jenkins denverdino/jenkins

Summarize

This article introduces the basic concept of Docker data volumes. We have provided a solution to the permission problem that occurs when non-root processes access local data volumes. We plan to continue to summarize some other problems encountered with Docker data volumes in the future.

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.