In the previous part, we introduced the basic methods and principles of Docker learning, as well as the basic three parts: mirror, container and warehouse. There are also Dockerfiles and data volumes.
Review:
Docker white introductory advice and basic principles
Docker (1) Images and containers
Docker files and data volumes
Today, xiaojiu will introduce users, networks and processes. It is very important to have a deep understanding of the concept and principle of Docker network in learning. Next, let’s learn together
network
Since the container is used to deploy applications, it needs to be frequently accessed by other services, so it is crucial to have a deep understanding of the concept and principle of Docker network.
networking
Docker systems have a Container routing function by default. Simply put, Docker generates an internal IP address for each Container deployed. For example, Docker automatically assigns 3 Intranet addresses when the container runs under Docker:
Container 1 172.18.0.1 Container 2 172.18.0.2 Container 3 172.18.0.23Copy the codeFor any Container, the IP address can be used as the access channel
port
Each Container can be mapped to a port on the server to facilitate external access to the Container. For example, MySQL is running on 172.18.0.1 and external access is enabled for MySQL. How to access MySQL from server IP address?
- First, do a port mapping for container 1 and add port 3306 mapped to the metropolis server
- You can then access MySQL through the server IP:3306
Question: Why does the application in Container have a port number? Container has the simplest operating system. If the operating system is installed, you must access the program through the port
The user
Generally speaking, Docker does not recommend running container processes as root, so Dockerfile writers create regular users in their code, and then run processes as regular users.
If no regular user is created, the container will run as root by default
The root of the container and the root of the host are the same user, but the permission of the root of the container is limited. If the — Privileged =true is added, it is equivalent to the root of the host
UID
Although there is a concept of a user name, the user object ultimately managed by the Linux kernel is identified by a UID, so this section uses a UID instead of a user name.
Because containers are independent processes based on virtual isolation and share the operating system kernel, and the kernel manages only one set of Uids and Gids, uids and Gids in containers are essentially the same system as the host kernel.
Understand the nature of User permissions, Uids, gids, and so on in containers, focusing on understanding Linux User Namespace
When a container process tries to write to a file, the kernel checks the uid and GID of the container to determine whether it has sufficient privileges to modify the file.
Right to mention
We will find in Dockerfile that when we need to invoke rights to the user, instead of su, we use a combination of the following two commands
- gosu
- exec
process
Some say the essence of a container is a process. Whether or not this is absolute, the importance of visible processes to containers is self-evident.
The query process
Run the Docker Top ContainerID command to query the process.
To help you understand this, let’s run a Docker application: Docker-wordpress (open New Window)
Then query the process of each container separately.
[root@test ~]# docker top wordpress-mysql
UID PID PPID C STIME TTY TIME CMD
polkitd 22107 22080 0 Aug01 ? 00:01:52 mysqld
[root@test ~]# docker top wordpress
UID PID PPID C STIME TTY TIME CMD
33 807 22090 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
33 1675 22090 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
33 2935 22090 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
33 21955 22090 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
root 22090 22054 0 Aug01 ? 00:00:06 apache2 -DFOREGROUND
33 26327 22090 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
33 28793 22090 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
33 30253 22090 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
33 31445 22090 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
33 31955 22090 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
33 32734 22090 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
Copy the codeYou can see that some containers run only one process, while others run multiple processes (Apache, as an HTTP server, is by nature multi-process).
You can also enter one of the containers and run the ps -ef command to view the process:
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Aug01 ? 00:00:06 apache2 -DFOREGROUND
www-data 153 1 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
www-data 181 1 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
www-data 193 1 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
www-data 209 1 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
www-data 214 1 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
www-data 215 1 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
www-data 218 1 0 Aug01 ? 00:00:01 apache2 -DFOREGROUND
www-data 219 1 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
www-data 224 1 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
www-data 225 1 0 Aug01 ? 00:00:00 apache2 -DFOREGROUND
root 253 0 0 06:17 pts/0 00:00:00 bash
root 261 253 0 06:18 pts/0 00:00:00 ps -ef
Copy the codeSo the effect is the same.
Open a Shell window and run the pstree -a command. The following process tree is displayed
├ ─ containerd shim - namespace moby - 8 a7712fe435afaa79c08e7281de7e1a658cd00261fecc7ba02da1847d47d1715 id - the address / run/containerd/containerd. The sock │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 - DFOREGROUND │ │ ├ ─ apache2 -Foreground │ ├─ Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises - Exercises └ ─ 12 * [{containerd - shim}] ├ ─ containerd shim - namespace moby - id D287c79eaced1fcdde94b2b6d45781937cb17a0ddf4848d26907dee40602e80f - address/run/containerd/containerd sock │ ├ ─ mysqld │ │ └ ─ 30 * [{mysqld}] │ └ ─ 13 * [{containerd - shim}]Copy the codeYou’ll notice that the query results are similar.
Create a process
Now that we have a very specific process impression from the above description, let’s dig a little deeper: how is the process of the container created?
The image provides the package and software environment that the container needs to run, but the container does not generate processes without starting various applications through CMD and ENTRYPOINT.
Unserved process
Containers are generally used to host services, but in development, container images can also be used as ephemeral processes: containerized executable commands running on our computers. These containers perform a single task, have a short life cycle, and can often be deleted after use. We call this an executable image, and the process of the container created by such an image can be called a non-server process.
The main process
There is a special process in Docker (PID=1 process), which is also the main process of Docker, specified by ENTRYPOINT and/or CMD directives in Dockerfile. When the main process exits, the container’s PIG namespace is destroyed, and the container’s life cycle ends. Docker best practice recommends one service per container, not one thread per container. Some services, such as Apache and UWSGi, spawn more child processes, which is perfectly acceptable.
The PID1 process is responsible for the child processes it creates. If the main process is not properly designed and cannot gracefully exit the child processes, many problems may occur, such as database Container. If the process that processes data does not gracefully exit, data loss may occur. If, unfortunately, your main process is one of those that cannot manage child processes, Docker provides a small tool to help you do this. All you need to do is provide a — init flag when the Run creates the container, and Docker takes care of it manually.
The main Docker process is a special process, and its life cycle is the life cycle of the Docker Container. It is responsible for the child process. When writing the Dockerfile, make sure that the PID1 process is defined.
The next part:
Docker quick learning (4) choreography, clustering and summary of common commands
This article is originally published by Websoft9.