深入理解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之类的普通进程能否接管孤儿进程），本文并没有进行测试

---

至此，本文结束

在下才疏学浅，有撒汤漏水的，请各位不吝赐教...