詳解如何在 docker 容器中捕獲信號(hào)
我們可能都使用過 docker stop 命令來停止正在運(yùn)行的容器,有時(shí)可能會(huì)使用 docker kill 命令強(qiáng)行關(guān)閉容器或者把某個(gè)信號(hào)傳遞給容器中的進(jìn)程。這些操作的本質(zhì)都是通過從主機(jī)向容器發(fā)送信號(hào)實(shí)現(xiàn)主機(jī)與容器中程序的交互。比如我們可以向容器中的應(yīng)用發(fā)送一個(gè)重新加載信號(hào),容器中的應(yīng)用程序在接到信號(hào)后執(zhí)行相應(yīng)的處理程序完成重新加載配置文件的任務(wù)。本文將介紹在 docker 容器中捕獲信號(hào)的基本知識(shí)。
信號(hào)(linux)
信號(hào)是一種進(jìn)程間通信的形式。一個(gè)信號(hào)就是內(nèi)核發(fā)送給進(jìn)程的一個(gè)消息,告訴進(jìn)程發(fā)生了某種事件。當(dāng)一個(gè)信號(hào)被發(fā)送給一個(gè)進(jìn)程后,進(jìn)程會(huì)立即中斷當(dāng)前的執(zhí)行流并開始執(zhí)行信號(hào)的處理程序。如果沒有為這個(gè)信號(hào)指定處理程序,就執(zhí)行默認(rèn)的處理程序。
進(jìn)程需要為自己感興趣的信號(hào)注冊(cè)處理程序,比如為了能讓程序優(yōu)雅的退出(接到退出的請(qǐng)求后能夠?qū)Y源進(jìn)行清理)一般程序都會(huì)處理 SIGTERM 信號(hào)。與 SIGTERM 信號(hào)不同,SIGKILL 信號(hào)會(huì)粗暴的結(jié)束一個(gè)進(jìn)程。因此我們的應(yīng)用應(yīng)該實(shí)現(xiàn)這樣的目錄:捕獲并處理 SIGTERM 信號(hào),從而優(yōu)雅的退出程序。如果我們失敗了,用戶就只能通過 SIGKILL 信號(hào)這一終極手段了。除了 SIGTERM 和 SIGKILL ,還有像 SIGUSR1 這樣的專門支持用戶自定義行為的信號(hào)。下面的代碼簡單的說明在 nodejs 中如何為一個(gè)信號(hào)注冊(cè)處理程序:
process.on('SIGTERM', function() { console.log('shutting down...'); });
關(guān)于信號(hào)的更多信息,筆者在《linux kill 命令》一文中有所提及,這里不再贅述。
容器中的信號(hào)
Docker 的 stop 和 kill 命令都是用來向容器發(fā)送信號(hào)的。注意,只有容器中的 1 號(hào)進(jìn)程能夠收到信號(hào),這一點(diǎn)非常關(guān)鍵!
stop 命令會(huì)首先發(fā)送 SIGTERM 信號(hào),并等待應(yīng)用優(yōu)雅的結(jié)束。如果發(fā)現(xiàn)應(yīng)用沒有結(jié)束(用戶可以指定等待的時(shí)間),就再發(fā)送一個(gè) SIGKILL 信號(hào)強(qiáng)行結(jié)束程序。
kill 命令默認(rèn)發(fā)送的是 SIGKILL 信號(hào),當(dāng)然你可以通過 -s 選項(xiàng)指定任何信號(hào)。
下面我們通過一個(gè) nodejs 應(yīng)用演示信號(hào)在容器中的工作過程。創(chuàng)建 app.js 文件,內(nèi)容如下:
'use strict'; var http = require('http'); var server = http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(3000, '0.0.0.0'); console.log('server started'); var signals = { 'SIGINT': 2, 'SIGTERM': 15 }; function shutdown(signal, value) { server.close(function () { console.log('server stopped by ' + signal); process.exit(128 + value); }); } Object.keys(signals).forEach(function (signal) { process.on(signal, function () { shutdown(signal, signals[signal]); }); });
這個(gè)應(yīng)用是一個(gè) http 服務(wù)器,監(jiān)聽端口 3000,為 SIGINT 和 SIGTERM 信號(hào)注冊(cè)了處理程序。接下來我們將介紹以不同的方式在容器中運(yùn)行程序時(shí)信號(hào)的處理情況。
應(yīng)用程序作為容器中的 1 號(hào)進(jìn)程
創(chuàng)建 Dockerfile 文件,把上面的應(yīng)用打包到鏡像中:
FROM iojs:onbuild COPY ./app.js ./app.js COPY ./package.json ./package.json EXPOSE 3000 ENTRYPOINT ["node", "app"]
請(qǐng)注意 ENTRYPOINT 指令的寫法,這種寫法會(huì)讓 node 在容器中以 1 號(hào)進(jìn)程的身份運(yùn)行。
接下來創(chuàng)建鏡像:
$ docker build --no-cache -t signal-app -f Dockerfile .
然后啟動(dòng)容器運(yùn)行應(yīng)用程序:
$ docker run -it --rm -p 3000:3000 --name="my-app" signal-app
此時(shí) node 應(yīng)用在容器中的進(jìn)程號(hào)為 1:
現(xiàn)在我們讓程序退出,執(zhí)行命令:
$ docker container kill --signal="SIGTERM" my-app
此時(shí)應(yīng)用會(huì)以我們期望的方式退出:
應(yīng)用程序不是容器中的 1 號(hào)進(jìn)程
創(chuàng)建一個(gè)啟動(dòng)應(yīng)用程序的腳本文件 app1.sh,內(nèi)容如下:
#!/usr/bin/env bash node app
然后創(chuàng)建 Dockerfile1 文件,內(nèi)容如下:
FROM iojs:onbuild COPY ./app.js ./app.js COPY ./app1.sh ./app1.sh COPY ./package.json ./package.json RUN chmod +x ./app1.sh EXPOSE 3000 ENTRYPOINT ["./app1.sh"]
接下來創(chuàng)建鏡像:
$ docker build --no-cache -t signal-app1 -f Dockerfile1 .
然后啟動(dòng)容器運(yùn)行應(yīng)用程序:
$ docker run -it --rm -p 3000:3000 --name="my-app1" signal-app1
此時(shí) node 應(yīng)用在容器中的進(jìn)程號(hào)不再是 1:
現(xiàn)在給 my-app1 發(fā)送 SIGTERM 信號(hào)試試,已經(jīng)無法退出程序了!在這個(gè)場景中,應(yīng)用程序由 bash 腳本啟動(dòng),bash 作為容器中的 1 號(hào)進(jìn)程收到了 SIGTERM 信號(hào),但是它沒有做出任何的響應(yīng)動(dòng)作。
我們可以通過:
$ docker container stop my-app1 # or $ docker container kill --signal="SIGKILL" my-app1
退出應(yīng)用,它們最終都是向容器中的 1 號(hào)進(jìn)程發(fā)送了 SIGKILL 信號(hào)。很顯然這不是我們期望的,我們希望程序能夠收到 SIGTERM 信號(hào)優(yōu)雅的退出。
在腳本中捕獲信號(hào)
創(chuàng)建另外一個(gè)啟動(dòng)應(yīng)用程序的腳本文件 app2.sh,內(nèi)容如下:
#!/usr/bin/env bash set -x pid=0 # SIGUSR1-handler my_handler() { echo "my_handler" } # SIGTERM-handler term_handler() { if [ $pid -ne 0 ]; then kill -SIGTERM "$pid" wait "$pid" fi exit 143; # 128 + 15 -- SIGTERM } # setup handlers # on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler trap 'kill ${!}; my_handler' SIGUSR1 trap 'kill ${!}; term_handler' SIGTERM # run application node app & pid="$!" # wait forever while true do tail -f /dev/null & wait ${!} done
這個(gè)腳本文件在啟動(dòng)應(yīng)用程序的同時(shí)可以捕獲發(fā)送給它的 SIGTERM 和 SIGUSR1 信號(hào),并為它們添加了處理程序。其中 SIGTERM 信號(hào)的處理程序就是向我們的 node 應(yīng)用程序發(fā)送 SIGTERM 信號(hào)。
然后創(chuàng)建 Dockerfile2 文件,內(nèi)容如下:
FROM iojs:onbuild COPY ./app.js ./app.js COPY ./app2.sh ./app2.sh COPY ./package.json ./package.json RUN chmod +x ./app2.sh EXPOSE 3000 ENTRYPOINT ["./app2.sh"]
接下來創(chuàng)建鏡像:
$ docker build --no-cache -t signal-app2 -f Dockerfile2 .
然后啟動(dòng)容器運(yùn)行應(yīng)用程序:
$ docker run -it --rm -p 3000:3000 --name="my-app2" signal-app2
此時(shí) node 應(yīng)用在容器中的進(jìn)程號(hào)也不是 1,但是它卻可以接收到 SIGTERM 信號(hào)并優(yōu)雅的退出了:
結(jié)論
容器中的 1 號(hào)進(jìn)程是非常重要的,如果它不能正確的處理相關(guān)的信號(hào),那么應(yīng)用程序退出的方式幾乎總是被強(qiáng)制殺死而不是優(yōu)雅的退出。究竟誰是 1 號(hào)進(jìn)程則主要由 EntryPoint, CMD, RUN 等指令的寫法決定,所以這些指令的使用是很有講究的。
以上就是本文的全部內(nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
- docker容器如何優(yōu)雅的終止詳解
- Docker 容器操作退出后進(jìn)入解決辦法
- Docker常用的清除容器鏡像命令小結(jié)
- Docker 解決容器時(shí)間與主機(jī)時(shí)間不一致的問題三種解決方案
- Docker為網(wǎng)絡(luò)bridge模式指定容器ip的方法
- 如何在Docker容器內(nèi)外互相拷貝數(shù)據(jù)
- Docker容器中文亂碼(修改docker容器編碼格式)的解決方案
- Docker 容器內(nèi)存監(jiān)控原理及應(yīng)用
- 詳解掛載運(yùn)行的docker容器中如何掛載文件系統(tǒng)
- 兩種方式創(chuàng)建docker鏡像的啟動(dòng)容器時(shí)區(qū)別介紹(總結(jié)篇)
相關(guān)文章
Docker存儲(chǔ)目錄問題以及如何修改Docker默認(rèn)存儲(chǔ)位置
在Docker中,默認(rèn)情況下數(shù)據(jù)存儲(chǔ)路徑為/var/lib/docker,隨著容器和鏡像數(shù)量的增加,這可能會(huì)占用大量磁盤空間,這篇文章主要給大家介紹了關(guān)于Docker存儲(chǔ)目錄問題以及如何修改Docker默認(rèn)存儲(chǔ)位置的相關(guān)資料,需要的朋友可以參考下2024-08-08Docker?Compose中如何限制容器的CPU和內(nèi)存使用
這篇文章主要為大家介紹了Docker?Compose中限制容器的CPU和內(nèi)存使用示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-05-05Docker Compose一鍵ELK部署的方法實(shí)現(xiàn)
這篇文章主要介紹了Docker Compose一鍵ELK部署的方法實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-01-01Docker使用Calico網(wǎng)絡(luò)模式配置及問題處理方法
這篇文章主要介紹了Docker使用Calico網(wǎng)絡(luò)模式配置及問題處理,設(shè)計(jì)思想是Calico不使用隧道或者NAT來實(shí)現(xiàn)轉(zhuǎn)發(fā),而是巧妙的把所有二三層流量轉(zhuǎn)換成三層流量,并通過host上路由配置完成跨host轉(zhuǎn)發(fā),需要的朋友可以參考下2022-11-11Docker搭建Zookeeper&Kafka集群的實(shí)現(xiàn)
這篇文章主要介紹了Docker搭建Zookeeper&Kafka集群的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-08-08docker compose 服務(wù)啟動(dòng)順序控制的方法
這篇文章主要介紹了docker compose 服務(wù)啟動(dòng)順序控制的方法,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-09-09