深入理解docker信号机制以及dumb-init的使用
一、前言
● 容器中部署的时候往往都是直接运行二进制文件或命令，这样对于容器的作用更加直观，但是也会出现新的问题，比如子进程的资源回收、释放、托管等，处理不好，便会成为可怕的僵尸进程
● 本文主要讨论一下docker容器中进程之间信号处理以及对进程管理的问题
二、环境准备
| 组件 | 版本 |
|---|---|
| OS | Ubuntu 18.04.1 LTS |
| docker | 18.06.0-ce |
三、测试脚本
首先准备一个测试脚本，该脚本主要的作用是接收信号量以及获取信号发送者的进程号：
semaphore.c
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
static struct sigaction siga;
static void signal_handler(int sig, siginfo_t *siginfo, void *context) {
pid_t sender_pid = siginfo->si_pid;
if(sig == SIGTERM) {
printf("received sign: [term] , the sender is [%d]\n", (int)sender_pid);
return;
}
return;
}
void main(int argc, char *argv[]) {
printf("process [%d] started...\n", getpid());
siga.sa_sigaction = *signal_handler;
siga.sa_flags |= SA_SIGINFO;
sigaction(SIGTERM, &siga, NULL);
while(1) {
sleep(10);
}
}测试一下：
首先编译运行
root@k8s-master:/tmp# gcc semaphore.c root@k8s-master:/tmp# ./a.out process [20765] started...
重新打开一个控制台，发送一个SIGTERM信号
root@k8s-master:~# echo $$ 20638 root@k8s-master:~# kill -15 20765
查看第一个控制台
root@k8s-master:/tmp# ./a.out process [20765] started... received sign: [term] , the sender is [20638]
看起来脚本已经可以正常工作了
它监听了发送来得SIGTERM信号，并且成功找出了发送者
注：
SIGTERM是杀或的killall命令发送到进程默认的信号，SIGTERM类似于问一个进程终止可好，让清理文件和关闭。说白了，就是对温柔的对待，而不是粗暴的霸王硬上弓
四、进程在docker中收到的信号量
进程作为docker容器中1号进程
1号进程是所有进程的父进程，它可以收到从docker引擎发送的信号量，从而温柔的关闭进程
root@k8s-master:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out ubuntu:latest /a.out process [1] started...
重新打开一个控制台
root@k8s-master:~# docker stop sem_test sem_test
回到第一个控制台
root@k8s-master:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out ubuntu:latest /a.out process [1] started... received sign: [term] , the sender is [0] root@k8s-master:/tmp#
作为1号进程确实正确收到了来自docker引擎的SIGTERM，此时它可以从容的清理掉内存栈、网络连接等资源
进程不是docker1号进程
root@k8s-master:~# docker exec -it sem_test bash root@77e2d4e0ed03:/# /a.out [1] 19 process [19] started...
重新打开一个控制台，查看进程树
查看进程树状态
root@c8d8af54136a:/# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 07:52 pts/0 00:00:00 bash root 15 1 0 07:52 pts/0 00:00:00 /a.out root 16 0 3 07:53 pts/1 00:00:00 bash root 27 16 0 07:53 pts/1 00:00:00 ps -ef
1号进程是一个非常普通的bash，a.out只不过是它的子进程而已
这时的a.out还能正确的接收到SIGTERM吗？
root@k8s-master:~# docker stop sem_test sem_test
查看第一个控制台状态：
root@k8s-master:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out ubuntu:latest bash root@c8d8af54136a:/# /a.out process [15] started... root@k8s-master:/tmp#
很遗憾，a.out没有收到SIGTERM，它被霸王硬上弓了
注：
根据docker官网docker stop的介绍：
The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.
docker stop会发送SIGTERM让应用程序回收资源，过了温柔期之后，会直接kill掉
五、dumb-init
● 从上面的测试来看，docker stop会向容器的1号进程发送SIGTERM
● 但是一个普通的1号进程收到SIGTERM并不会向它的子进程做任何处理
● 所以我们需要一个优秀的父进程来接收来自docker的信号，并且传递给它的儿子们
dumb-init可以帮助我们解决1号进程的问题：
https://github.com/Yelp/dumb-init
下载一个最新版：
wget https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_amd64 -O dumb-init
通过dumb-init运行a.out
root@k8s-master:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out -v /tmp/dumb-init:/dumb-init ubuntu:latest /dumb-init /a.out process [8] started...
打开一个新的控制台查看进程树：
root@k8s-master:/tmp# docker exec -it sem_test bash root@09d494ac6ae3:/# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 08:08 ? 00:00:00 /dumb-init /a.out root 8 1 0 08:08 pts/0 00:00:00 /a.out root 9 0 3 08:09 pts/1 00:00:00 bash root 20 9 0 08:09 pts/1 00:00:00 ps -ef
此时，1号进程变成了dumb-init，并且a.out是它的子进程
关闭容器：
root@k8s-master:/tmp# docker stop sem_test sem_test
查看状态：
root@k8s-master:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out -v /tmp/dumb-init:/dumb-init ubuntu:latest /dumb-init /a.out process [8] started... received sign: [term] , the sender is [1] root@k8s-master:/tmp#
a.out成功收到来自1号进程（dumb-init）发送的信号SIGTERM，这下它可以从容的回收自己的资源了
六、小结
● docker引擎会向容器中1号进程发送信号，如果你的1号进程具备处理子进程各种状态的能力，那完全可以直接启动（比如nginx会处理它的worker进程）；否则就需要使用像dumb-init之类的来充当1号进程
● 关于容器中僵尸进程的测试（像bash、sleep之类的普通进程能否接管孤儿进程），本文并没有进行测试