前言
在Docker大行其道的今天,我們能夠非常方便的使用容器打包我們的應(yīng)用程序,并且將它在我們的服務(wù)器上部署并運行起來。但是,談?wù)摰饺绾瓮5暨\行中的docker容器并正確的終止其中的程序,這就成為一個非常值得討論的話題了。
事實上,在我們?nèi)粘5捻椖慨斨校@是我們經(jīng)常需要面對和處理的問題:
場景A:假如我們打包在容器中的程序,提供HTTP方式的服務(wù),負責處理各種HTTP requests并返回結(jié)果,我們必然希望在容器被停掉的時候,能夠讓程序有時間把已經(jīng)在處理中的請求繼續(xù)處理完畢,并返回結(jié)果給客戶端。
場景B:又比如我們打包在容器中的程序,負責寫入數(shù)據(jù)到某個數(shù)據(jù)文件中,我們希望程序能夠在容器被停掉的時候,有時間把內(nèi)存中緩存的數(shù)據(jù)持久化到存儲設(shè)備中,以防數(shù)據(jù)丟失。
場景C:再比如現(xiàn)在流行的微服務(wù)架構(gòu)中,一般會有服務(wù)發(fā)現(xiàn)的機制,也即每一個微服務(wù)在啟動之后,都會主動把自己的地址信息注冊到服務(wù)發(fā)現(xiàn)模塊當中,讓其他的服務(wù)可以知道自己的存在。而在容器被停掉的時候,微服務(wù)需要即時從服務(wù)發(fā)現(xiàn)模塊中注銷自己,以防止從API Gateway而來的請求被錯誤的路由到了已經(jīng)被停止掉的微服務(wù)。
如上的各種場景中,都要求打包在容器中的應(yīng)用程序能夠被優(yōu)雅的終止(也即gracefully shutdown),這種gracefully shutdown的方式,允許程序在容器被停止的時候,有一定時間做一些后續(xù)處理操作,這也是我們需要進一步探討的話題。
docker stop 與 docker kill 的區(qū)別
Docker本身提供了兩種終止容器運行的方式,即docker stop與docker kill。
docker stop
先來說說docker stop吧,當我們用docker stop命令來停掉容器的時候,docker默認會允許容器中的應(yīng)用程序有10秒的時間用以終止運行。所以我們查看docker stop命令幫助的時候,會有如下的提示:
→ docker stop --helpUsage: docker stop [OPTIONS] CONTAINER [CONTAINER...]Stop one or more running containersOptions: --help Print usage -t, --time int Seconds to wait for stop before killing it (default 10)
在docker stop命令執(zhí)行的時候,會先向容器中PID為1的進程發(fā)送系統(tǒng)信號SIGTERM,然后等待容器中的應(yīng)用程序終止執(zhí)行,如果等待時間達到設(shè)定的超時時間,或者默認的10秒,會繼續(xù)發(fā)送SIGKILL的系統(tǒng)信號強行kill掉進程。在容器中的應(yīng)用程序,可以選擇忽略和不處理SIGTERM信號,不過一旦達到超時時間,程序就會被系統(tǒng)強行kill掉,因為SIGKILL信號是直接發(fā)往系統(tǒng)內(nèi)核的,應(yīng)用程序沒有機會去處理它。在使用docker stop命令的時候,我們唯一能控制的是超時時間,比如設(shè)置為20秒超時:
docker stop --time=20 container_name
docker kill
接著我們來看看docker kill命令,默認情況下,docker kill命令不會給容器中的應(yīng)用程序有任何gracefully shutdown的機會。它會直接發(fā)出SIGKILL的系統(tǒng)信號,以強行終止容器中程序的運行。通過查看docker kill命令的幫助,我們可以看到,除了默認發(fā)送SIGKILL信號外,還允許我們發(fā)送一些自定義的系統(tǒng)信號:
→ docker kill --helpUsage: docker kill [OPTIONS] CONTAINER [CONTAINER...]Kill one or more running containersOptions: --help Print usage -s, --signal string Signal to send to the container (default "KILL")
新聞熱點
疑難解答
圖片精選