深入理解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); } }
測試一下：
首先編譯執行
[email protected]:/tmp# gcc semaphore.c
[email protected]:/tmp# ./a.out
process [20765] started...重新開啟一個控制檯，傳送一個SIGTERM訊號
[email protected]:~# echo $$
20638
[email protected]:~# kill -15 20765檢視第一個控制檯
[email protected]:/tmp# ./a.out process [20765] started... received sign: [term] , the sender is [20638]
看起來指令碼已經可以正常工作了
它監聽了傳送來得SIGTERM訊號，並且成功找出了傳送者
注：
SIGTERM是殺或的killall命令傳送到程序預設的訊號，SIGTERM類似於問一個程序終止可好，讓清理檔案和關閉。說白了，就是對溫柔的對待，而不是粗暴的霸王硬上弓
四、程序在docker中收到的訊號量
程序作為docker容器中1號程序
1號程序是所有程序的父程序，它可以收到從docker引擎傳送的訊號量，從而溫柔的關閉程序
[email protected]:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out ubuntu:latest /a.out
process [1] started...重新開啟一個控制檯
[email protected]:~# docker stop sem_test
sem_test回到第一個控制檯
[email protected]:/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]
[email protected]:/tmp#作為1號程序確實正確收到了來自docker引擎的SIGTERM，此時它可以從容的清理掉記憶體棧、網路連線等資源
程序不是docker1號程序
[email protected]:~# docker exec -it sem_test bash
[email protected]:/# /a.out
[1] 19
process [19] started...
重新開啟一個控制檯，檢視程序樹
檢視程序樹狀態
[email protected]:/# 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 -ef1號程序是一個非常普通的bash，a.out只不過是它的子程序而已
這時的a.out還能正確的接收到SIGTERM嗎？
[email protected]:~# docker stop sem_test
sem_test檢視第一個控制檯狀態：
[email protected]:/tmp# docker run --name sem_test --rm -it -v /tmp/a.out:/a.out ubuntu:latest bash
[email protected]:/# /a.out
process [15] started...
[email protected]:/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
[email protected]:/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...開啟一個新的控制檯檢視程序樹：
[email protected]:/tmp# docker exec -it sem_test bash
[email protected]:/# 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是它的子程序
關閉容器：
[email protected]:/tmp# docker stop sem_test
sem_test檢視狀態：
[email protected]:/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]
[email protected]:/tmp#a.out成功收到來自1號程序（dumb-init）傳送的訊號SIGTERM，這下它可以從容的回收自己的資源了
六、小結
● docker引擎會向容器中1號程序傳送訊號，如果你的1號程序具備處理子程序各種狀態的能力，那完全可以直接啟動（比如nginx會處理它的worker程序）；否則就需要使用像dumb-init之類的來充當1號程序
● 關於容器中殭屍程序的測試（像bash、sleep之類的普通程序能否接管孤兒程序），本文並沒有進行測試
至此，本文結束
在下才疏學淺，有撒湯漏水的，請各位不吝賜教...