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

In this issue, the editor will bring you about the elegant termination scheme of Docker container. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

As a system restart engineer (SRE), you may often need to restart the container. After all, Kubernetes has the advantages of fast auto scaling and fault recovery. If you encounter problems, restart the container first, and then restore it in a few seconds. You really can't restart the system again. This is the killer mace of system restart engineers. However, the reality is not as good as in theory, some containers take about 10 seconds to stop, this is why? There are several possibilities:

The process in the container did not receive a SIGTERM signal.

The process in the container received the signal but ignored it.

It is true that the closing time of applications in the container is that long.

There is nothing we can do about the third possibility, mainly dealing with 1 and 2.

If you want to build a new Docker image, you must want the image to be as small as possible, so that it downloads and starts quickly. We usually choose a slimmed-down operating system (such as Alpine,Busybox, etc.) as the basic image.

This is the problem, these basic mirrored init systems have also been erased, this is the root of the problem!

The init system has the following characteristics:

It is the first process of the system and is responsible for generating all other user processes.

Init exists as a daemon and is the ancestor of all other processes.

It is mainly responsible for:

Start the daemon

Recovery of orphans process

Forward the operating system signal to the child process

1. Docker container stop process

The init system is not required for the container, and when you stop the container by calling docker stop mycontainer, docker CLI will send the TERM signal to mycontainer's PID 1 process.

If PID 1 is an init process-then PID 1 forwards the TERM signal to the child process, then the child process starts shutting down, and the container terminates.

If there is no init process-then the application process in the container (the ENTRYPOINT in Dockerfile or the application specified by CMD) is PID 1, and the application process is directly responsible for responding to TERM signals. At this time, it is divided into two situations:

The application does not process SIGTERM-if the application does not listen for the SIGTERM signal, or if the application does not implement the logic to process the SIGTERM signal, the application will not stop and the container will not terminate.

The container stops for a long time-after running the command docker stop mycontainer, Docker waits for 10 seconds. If the container is not terminated after 10 seconds, Docker will bypass the container application and send SIGKILL directly to the kernel, and the kernel will forcibly kill the application, thus terminating the container.

two。 Can't the container process receive the SIGTERM signal?

If the process in the container does not receive the SIGTERM signal, it is most likely because the application process is not PID 1 Magi pid 1 is shell, and the application process is only a child process of shell. The shell does not have the function of the init system, so it will not forward the signal of the operating system to the child process, which is a common reason why the application in the container does not receive the SIGTERM signal.

The root of the problem comes from Dockerfile, such as:

FROM alpine:3.7COPY popcorn.sh .Run chmod + x popcorn.shENTRYPOINT. / popcorn.sh

The ENTRYPOINT instruction uses shell mode, so Docker will run the application in shell, so shell is PID 1.

There are several solutions:

Scenario 1: using ENTRYPOINT instructions in exec mode

Instead of using shell mode, use exec mode, for example:

FROM alpine:3.7COPY popcorn.sh .Run chmod + x popcorn.shENTRYPOINT [". / popcorn.sh"]

So PID 1 is. / popcorn.sh, which will be responsible for responding to all signals sent to the container, but whether. / popcorn.sh can actually capture the system signal is another matter.

For example, suppose you use the Dockerfile above to build the image, and the popcorn.sh script prints the date every second:

#! / bin/shwhile truedo date sleep 1done

Build the image and create the container:

→ docker build-t truek8s/popcorn. → docker run-it-- name corny-- rm truek8s/popcorn

Open another terminal to execute the command to stop the container and time it:

? → time docker stop corny

Because popcorn.sh does not implement the logic to capture and process SIGTERM signals, it takes about 10 seconds to stop the container. To solve this problem, add signal processing code to the script to terminate the process when it catches the SIGTERM signal:

#! / bin/sh# catch the TERM signal and then exittrap "exit" TERMwhile truedo date sleep 1done

Note: the following instruction is equivalent to the ENTRYPOINT instruction in shell mode:

ENTRYPOINT ["/ bin/sh", ". / popcorn.sh"] scenario 2: use the exec command directly

If you just want to use the ENTRYPOINT instruction in shell mode, it's not impossible, just append the startup command to exec, for example:

FROM alpine:3.7COPY popcorn.sh .Run chmod + x popcorn.shENTRYPOINT exec. / popcorn.sh

In this way, exec replaces the shell process with the. / popcorn.sh process, and PID 1 is still. / popcorn.sh.

Option 3: use the init system

If the application in the container cannot handle the SIGTERM signal by default and cannot modify the code, then neither solution 1 nor solution 2 will work, so you can only add an init system to the container. There are many kinds of init systems. It is recommended to use tini, which is a lightweight init system dedicated to containers and is easy to use:

Install tini

Set tini as the default application of the container

Use popcorn.sh as a parameter for tini

The specific Dockerfile is as follows:

FROM alpine:3.7COPY popcorn.sh .Run chmod + x popcorn.shRUN apk add-no-cache tiniENTRYPOINT ["/ sbin/tini", "-", ". / popcorn.sh"]

Tini is now PID 1, which forwards the received system signal to the child process popcorn.sh.

If you want to run the container directly through the docker command, you can use tini directly with the parameter-- init. You don't need to install tini in the image. If it's Kubernetes, it won't work, and you have to install tini honestly.

3. Does the application still need to deal with SIGTERM after using tini?

One last question: if we remove the processing logic for SIGTERM signals in popcorn.sh, will the container terminate immediately after we execute the stop command?

The answer is yes. In the Linux system, PID 1 is different from other processes. To be exact, the init process is different from other processes. It does not perform the default actions related to the received signals. It must explicitly implement the logic of capturing and processing SIGTERM signals in the code. Scenarios 1 and 2 do this.

An ordinary process is much simpler, as long as it receives a system signal, it performs the default action associated with that signal, and does not need to display the implementation logic in the code, so it can be terminated gracefully.

This is what the elegant termination scheme of Docker container shared by Xiaobian is like. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.