background
A new batch processing function is launched based on Docker release. After going online, there was a problem that the file directory generated by Docker batch processing could not be accessed by other applications.
I was using Docker before, but it didn't involve file sharing, so I really didn't notice it. After a series of investigations, the reason was finally found. This article will record the technical points used in the investigation process, and also help you review them.
Knowledge points involved: Docker help command, Linux user/group id view, Docker user specification, Docker startup failure log view, etc.
Phenomena analysis
The project run by Docker regularly creates a file directory and performs operations such as file generation, but when other applications operate the directory generated by the Docker application, a "Permission denied" error will be prompted.
Check the folder permissions generated by Docker, it was created by the root user. Executing the Docker startup script is obviously an ordinary user, so why does the generated file become a root user?
This involves the user used when executing the execution through Docker. If no user is specified when executing the Docker command, it will be executed as the root user by default. Of course it is not allowed in this production environment.
problem solved
Now that it is easier to find the cause of the problem, let’s record some Docker commands and Linux operations involved in solving the problem.
Query help documents
Let's first check the command parameters of Docker through the help command, and how to specify the user who executes the command.
Tried docker --helpthe command first, but did not find the command parameters for the specified user:
$ sudo docker --help
Usage: docker [OPTIONS] COMMAND
A self-sufficient runtime for containers
Options:
--config string Location of client config files (default "/root/.docker")
-c, --context string Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use")
-D, --debug Enable debug mode
-H, --host list Daemon socket(s) to connect to
-l, --log-level string Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
--tls Use TLS; implied by --tlsverify
--tlscacert string Trust certs signed only by this CA (default "/root/.docker/ca.pem")
--tlscert string Path to TLS certificate file (default "/root/.docker/cert.pem")
--tlskey string Path to TLS key file (default "/root/.docker/key.pem")
--tlsverify Use TLS and verify the remote
-v, --version Print version information and quit
It was only later that I realized that what I was looking for should be the help documentation for docker's run command:
$ sudo docker run --help
...
-u, --user string Username or UID (format: <name|uid>[:<group|gid>])
--userns string User namespace to use
--uts string UTS namespace to use
...
Among them, there are user parameters that specify the operation of the run command, through which -uthe user and group that execute the command can be specified.
docker specified user
Referring to the help manual, the running commands of docker (pseudocode) are sorted out:
$ sudo docker run -itd -u testuser -p 8080:8080 -v /log/:/log xxx-job:latest
In the above command -u username, the user who executes the command is specified, so it can be executed normally, but the following exception information is thrown during execution:
docker: Error response from daemon: unable to find user testuser: no matching entries in passwd file.'
Although the current user is testuser, docker does not seem to find it in the passwd file. At this time, the Username is directly replaced by the user's UID.
Get Linux user UID
There are two ways to get the UID of a Linux user.
Method 1: Execute the command.
Get UID command:
$ id -u
1002
The UID of the current user is 1002.
Get group ID command:
$ id -g
1002
The group ID to which the current user belongs is 1002.
Method 2: View /etc/passwd to obtain the UID and group ID.
Execute cat /etc/passwdthe command to display the contents of /etc/passwd.
Find the UID and group ID corresponding to the current user in /etc/passwd.
Adjust Docker commands
After obtaining the UID and group ID of the current user, the Docker running command is modified as follows:
$ sudo docker run -itd -u 1002:1002 -p 8080:8080 -v /log/:/log xxx-job:latest
Normally, the problem is solved here, and the application can be started normally.
Docker log view
But the author encountered another problem, which is the log of the application in Docker. Due to the previous mistake, it was created by the root user by default. At this time, I used testuser to start the application and found that Docker could not be started. The reason is very simple. The application started by testuser cannot Write logs to log files created by root.
The command to view the Docker failure log is used to check the startup failure:
docker logs 97069f94437b
At this point, either back up the original log and let the system regenerate the log file, or directly modify the log file permission to testuser.
So far, the issue of Docker generated directory permissions has been solved.
summary
In fact, the cause of the above problem is very small, that is, a parameter was missed. But if you don't go through a thing, you don't gain a wisdom. Maybe many friends may not have noticed this problem in the process of using Docker.
The troubleshooting process is also very interesting. It not only involves the operation commands of Docker, but also involves some basic knowledge of Linux. Knowledge and skills are grown in the process of problem occurrence and problem solving.
After solving the above problems, I not only feel that " pure pedantic technical learning is still flawed after all, it must be practiced and must be clinically practiced! "