深入理解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