Docker故障檢測和排除最佳實踐

1、 Docker 故障檢測和排除最佳實踐 【導(dǎo)讀】在以Docker+kubernetes為代表的通用型容器云平臺，容器引擎Docker自身的可視化和儀表化程度還不夠，除此之外，比較理想的是，我們應(yīng)該通過一種科學(xué)的方式對Docker進(jìn)行故障檢測和排除。本文將通過三個方面對此進(jìn)行論述，主要是使用docker exec來檢查容器、對docker的外部進(jìn)行調(diào)試、通過其他的工具和組件進(jìn)行檢測。同時列舉了多個案例來描述了使用Docker過程中遇到的常見的問題，如啟動時、運(yùn)用中的一些場景。1. 檢查容器對服務(wù)器進(jìn)行故障檢測和排除時，傳統(tǒng)的調(diào)試方法為登錄到相應(yīng)的機(jī)器上進(jìn)行查看。在Docker中，典型的工作流程分

2、為兩步：首先使用標(biāo)準(zhǔn)的遠(yuǎn)程登錄工具登錄到docker宿主機(jī)上，然后使用docker exec進(jìn)入指定的、運(yùn)行中的容器進(jìn)程命名空間中，作為調(diào)試應(yīng)用的一種手段，這是最直接而且有效的。下面我們舉一個例子，對運(yùn)行haproxy的Docker容器進(jìn)行故障檢測、排除和調(diào)試。我們先創(chuàng)建haproxy的配置文件haproxy.cfg。使用官方推薦的haproxy docker鏡像和創(chuàng)建的配置，運(yùn)行該容器。在docker宿主機(jī)上，運(yùn)行以下命令來啟動該haproxy容器：dockerhost$ docker run d p 80:80 name haproxy -v pwd/haproxy.cfg:/usr/lo

3、cal/etc/haproxy/haproxy.cfg haproxy:1.5.14現(xiàn)在進(jìn)入檢查容器并調(diào)試階段。具體案例如下，如果確認(rèn)haproxy容器是否在監(jiān)聽80端口，ss程序可以在絕大多數(shù)的liunux發(fā)行版上打印出套接字統(tǒng)計信息的小結(jié)?？梢赃\(yùn)行以下命令，來顯示docker容器內(nèi)正在監(jiān)聽的套接字的統(tǒng)計信息。dockerhost$ docker exec haproxy /bin/ss l由于ss已經(jīng)在haproxy：1.5.14的父容器linux:jessie中默認(rèn)安裝了，所以docker exec這種方法才能起到作用。我們不能使用類似于netstat的工具，因為它默認(rèn)沒有被安裝，運(yùn)行n

4、etstat命令會引起下列的報錯。dockerhost$ docker exec haproxy /bin/netstat andockernost$ echo $?255我們可以查看docker引擎服務(wù)的日志，來查看容器發(fā)生了什么，輸入以下命令會顯示，在我們的容器中netstat程序并不存在，具體命令如下。dockerhost$ journalctl u docker.service o cat另一種查看netstat是否安裝的方法就是交互式的進(jìn)入容器中，docker exec命令有特殊的選項-it，可以用來打開一個交互式的shell會話來進(jìn)行調(diào)試，在bash中輸入命令dockerhost$

5、 docker exec it haproxy /bin/bash在這個案例中，我們介紹了通過docker exec命令的方式來對容器進(jìn)行調(diào)試和突發(fā)問題的排查，同時使用了-it選項，還可以通過交互式的命令進(jìn)行更加深入的調(diào)試。但是，docker exec也有一定的局限性，原因是我們假設(shè)所有的工具已經(jīng)默認(rèn)安裝在docker容器中，這也是容器的體量過于龐大。2. 從外部進(jìn)行調(diào)試盡管容器隔離了容器的網(wǎng)絡(luò)、內(nèi)存、存儲資源，但是每個單獨的容器仍然需要docker宿主機(jī)的操作系統(tǒng)來執(zhí)行真正的命令，所以我們可以通過這個特性，從外部來檢查和調(diào)試docker容器。在此，基于此特性，我們可以在docker宿主機(jī)或者

6、具備一定權(quán)限，如高級權(quán)限、elevated privileges的兄弟容器sibling container中，來查看docker宿主機(jī)中的組件。（1）追蹤系統(tǒng)調(diào)用在服務(wù)器操作中，系統(tǒng)調(diào)用軌跡systemcall tracer是一個很實用的工具，它可以檢查并記錄被調(diào)用的系統(tǒng)調(diào)用，每個操作系統(tǒng)都是它的變形，即使我們在docker容器中運(yùn)行不同的應(yīng)用和進(jìn)程，歸根結(jié)底也會以系統(tǒng)調(diào)用的形式進(jìn)入docker宿主機(jī)的linux操作系統(tǒng)。在Linux系統(tǒng)中，strace程序可以用來記錄系統(tǒng)調(diào)用，strace的攔截和日志功能可以從外部檢查docker容器，容器生命周期中調(diào)用的系統(tǒng)調(diào)用列表可以描述出容器是如何運(yùn)

7、行的。接著以上的案例，我們用strace來檢查haproxy容器的系統(tǒng)調(diào)用，命令如下。通過以上命令，可以看到haproxy容器調(diào)用了epoll_wait（）等待網(wǎng)絡(luò)連接。同步在另一個終端，輸入以下命令，向容器發(fā)送http請求，命令如下。$ curl http:/dockerhost，然后重回strace程序，可以看到如下內(nèi)容?？梢钥吹剑琱aproxy調(diào)用了標(biāo)準(zhǔn)的bsd風(fēng)格的套接字系統(tǒng)調(diào)用，如accept4（）、socker（）、close（），來接收、處理和關(guān)閉來自http客戶端的網(wǎng)絡(luò)連接。同時，即使haproxy在處理連接過程中，epoll_wait（）仍然在不斷的被調(diào)用，從這里可以看到ha

8、proxy是如何處理并發(fā)連接。追蹤系統(tǒng)調(diào)用是一個非常有用而且科學(xué)的技術(shù)，可以用來調(diào)試在容器云平臺上承載的生產(chǎn)系統(tǒng)，維護(hù)人員在沒有訪問源碼的情況下，只有生產(chǎn)環(huán)境中編譯好的二進(jìn)制文件，或者docker鏡像。在線上運(yùn)行的系統(tǒng)，可以通過追蹤系統(tǒng)調(diào)用的方式獲得查找問題的第一手線索。（2）網(wǎng)絡(luò)數(shù)據(jù)包的分析在容器云平臺架構(gòu)中，絕大多數(shù)的docker容器都提供了某種形式的網(wǎng)絡(luò)服務(wù)，因此，在本小節(jié)的案例中，haproxy容器承載的主要是http網(wǎng)絡(luò)流量。無論我們運(yùn)行的是什么容器，網(wǎng)絡(luò)數(shù)據(jù)包最終都是由docker宿主機(jī)發(fā)出，從而完成請求。通過打印和分析數(shù)據(jù)包的內(nèi)容，我們可以了解到容器的本質(zhì)，因此根據(jù)haproxy

9、的案例，我們使用tcpdump抓包工具來分析docker容器接收和發(fā)送的網(wǎng)絡(luò)數(shù)據(jù)包流量。下面我們通過一個簡單的例子來說明，在docker宿主機(jī)運(yùn)行如下命令，發(fā)現(xiàn)在centos：jessie容器中不能解析。dockerhost$ docker run it centos:jessie /bin/bashrootfce09c80e16:/# ping ping:unknown host在另一個單獨的終端運(yùn)行tcpdump，當(dāng)運(yùn)行ping命令的時候，注意tcpdump有如下的輸出。dockerhost$ tcpdump i docker0可以看到，/bin/bash正在尋找，這通常是docker引擎

10、的網(wǎng)卡地址docker0的ip地址，然后我們輸入一下命令來查看docker0。dockerhost$ ip addr show dev docker0通過以上返回結(jié)果，我們發(fā)現(xiàn)問題，網(wǎng)卡接口docker0沒有制定ipv4地址，在某些場景，docker0上映射的ip地址會存在丟失的現(xiàn)象，最簡單的解決方案重啟docker引擎便可以解決。docker會重新初始化docker0網(wǎng)卡接口。下面在docker宿主機(jī)上，輸入以下命令來重啟docker引擎。dockerhost$ systemctl restart docker.service現(xiàn)在我們運(yùn)行上述相同的命令，ip地址已被指定。（3）觀察塊設(shè)備Do

11、cker容器將數(shù)據(jù)存儲在物理存儲設(shè)備上，比如普通硬盤或SSD，Docker底層的寫時復(fù)制文件系統(tǒng)是一個隨機(jī)訪問的物理設(shè)備，這些設(shè)備被組織成塊設(shè)備，而數(shù)據(jù)被組織為固定大小、可以隨機(jī)訪問的塊，也稱之為blocks。由于docker容器有一些特殊的io行為和性能問題，我們可以使用blktrace工具來追蹤、檢查故障和排除塊設(shè)備中的問題。這個程序可以檢測到進(jìn)程如何和塊設(shè)備進(jìn)行交互的內(nèi)核事件，在這個小節(jié)中，我們將設(shè)置docker宿主機(jī)，來觀察容器底層的塊設(shè)備。首先在docker宿主機(jī)上，通過下列命令來安裝blktrace程序。dockerhost$ apt-get install y blktrace此

12、外我們需要開啟文件系統(tǒng)的調(diào)試選項，命令如下dockerhost$ mount t debugfs debugfs /sys/kernel/debug正式進(jìn)入調(diào)試環(huán)節(jié)，我們需要定義blktrace在哪里監(jiān)聽io事件，為了追蹤容器的io事件，我們需要知道docker運(yùn)行時的根文件的目錄位置。這個步驟中，docker宿主機(jī)的默認(rèn)配置為指向/var/lib/docker，因此我們可以輕易的找到根目錄隸屬于宿主機(jī)的哪個分區(qū)。我們可以做一個模擬，在容器內(nèi)創(chuàng)建一個空文件，一直到根分區(qū)耗盡空閑的資源，從而在磁盤上產(chǎn)生io事件，輸入以下命令產(chǎn)生負(fù)載。dockerhost$ docker run d name d

13、ump centos:jessie /bin/dd if=/dev/zeroof=/root/dump bs=65000我們將得到產(chǎn)生io時間的docker容器pid，獲取pid的方式見上一小節(jié)。在此我們可以使用blktrace的輔助工具blkparse。blktrace程序只監(jiān)聽linux內(nèi)核的塊io層，并將結(jié)果輸出到文件中，blkparse程序可以查看和分析這些事件。輸入以下命令，在產(chǎn)生的負(fù)載中找到docker容器的pid對應(yīng)的io事件。dockerhost$ blkarse i dump.blktrace.0 | grep “$pid”從上面的輸出可以得到，在塊設(shè)備dm-0的偏移量為11

14、001856的位置，有一次1024字節(jié)的寫入，并已經(jīng)完成。為了更進(jìn)一步的排查問題，我們可以查看事件產(chǎn)生的偏移量文字，輸入以下命令，來過濾出偏移量的位置。dockerhost$ blkarse i dump.blktrace.0 | grep “11001856”可以看到寫入已經(jīng)被kworker進(jìn)程放入了設(shè)備的隊列中，也就是說，寫入操作被內(nèi)核加入到隊列中。在40毫秒滯后，docker容器進(jìn)程的寫入請求已經(jīng)完成了。通過這個案例我們可以查看docker容器中更為詳細(xì)的io行為，并找出相應(yīng)應(yīng)用的瓶頸，可以預(yù)見的應(yīng)用是否產(chǎn)生了太多的寫請求，大量的讀請求，從而引發(fā)容器的故障。（4）故障檢測和排除工具調(diào)試D

15、ocker容器中的應(yīng)用和調(diào)試Linux中的應(yīng)用是不同的，但是真正使用的程序是相同的，因為容器中發(fā)出的系統(tǒng)調(diào)用最終是進(jìn)入docker宿主機(jī)的操作系統(tǒng)。通過了解容器產(chǎn)生的系統(tǒng)調(diào)用，我們可以使用任意的調(diào)試工具來進(jìn)行容器突發(fā)情況的故障檢測和排除。除了標(biāo)準(zhǔn)的Linux工具之外，有很多針對容器的工具集，集成了一系列的標(biāo)準(zhǔn)工具，對于容器使用和故障排查方面更加友好，在此推薦大家一些成熟的工具。紅帽的rhel-tools docer鏡像是一個巨大的容器，集成了我們本章節(jié)所提到的所有的工具。core的toolbox程序是一個精簡的腳本工具，可以使用systemd的systemd-nspawn程序創(chuàng)建一個小的Lin

16、ux容器，通過復(fù)制流行的docker容器根文件系統(tǒng)，可以安裝任意一款工具而不會污染宿主機(jī)的文件系統(tǒng)。3. 容器的常見故障舉例在實際的使用中，除了上述的網(wǎng)絡(luò)、磁盤因素外，還有各種各樣的故障，一般有三類。應(yīng)用故障：應(yīng)用的執(zhí)行狀態(tài)和預(yù)期的不一致；容器故障：無法正確的創(chuàng)建、停止、更新容器；集群故障：集群創(chuàng)建失敗、更新失敗和無法連接。以下會舉一些常見的案例來進(jìn)行說明。1、在生產(chǎn)環(huán)境中，全新未投產(chǎn)的docker無法啟動，具體的報錯如下。systemctlstart docker.servicejob for docker.service failed becausethe control process

17、exited with error code.seesystemctl status docker.service andjournalctl -xe for details通過journalctl xe命令查看容器啟動的詳細(xì)日志，發(fā)現(xiàn)啟動deamon錯誤，因為selinux不支持，selinux阻擋docker容器引擎的啟動，具體報錯如下。error starting daemon: selinux is notsupported with the overlay2 graph driver on this kernel. either boot into anewer kernel or

18、disable selinux in docker (-selinux-enabled=false)解決方案一般有兩種，關(guān)閉宿主機(jī)selinux配置文件，/etc/selinux/config，將配置文件中enforcing設(shè)置為disabled，然后重啟系統(tǒng)，然后重啟docker引擎即可。關(guān)閉docker主配置文件，/etc/sysconfig/docker，將配置文件中-selinux-enabled選項為false，改成：-selinux-enabled=false即可。2、在實際使用中，發(fā)現(xiàn)docker虛擬化引擎存在如下報錯，chown socket at step group：no

19、such process，報錯截圖如下。上述錯誤提示因為docker無法找到當(dāng)前的group組信息，docker組有可能被誤操作刪除，一般解決方法有兩種。方法一創(chuàng)建宿主機(jī)docker組即可，命令為groupadd docker。方法二對docker配置文件，/usr/lib/systemd/system/docker.socket文件，socketgroup=修改為root。3、在實際使用中，發(fā)現(xiàn)docker虛擬化引擎存在如下報錯，attach_loopback.go:42 there are no more loopback devices available，具體截圖如下。該錯誤提示因為l

20、inux操作系統(tǒng)沒有更多的loopback設(shè)備提供至docker使用，解決方法為創(chuàng)建更多的loopback設(shè)備，具體命令如下。for i inseq 0 6;do mknod -m 0660 /dev/loop$i b 7 $i;done4、在實際使用中，對docker進(jìn)行操作，當(dāng)執(zhí)行docker命令時，有如下報錯。cannot connect to the docker daemon at unix:/var/run/docker.sock. is the docker daemon running?該報錯提示docker容器沒有被正常啟動解決方法如下，首先檢測docker進(jìn)程是否正常啟動，

21、可以通過ps -ef|grep docker，如果沒有啟動，啟動docker即可。檢測docker進(jìn)程存在，但是無法連接，可以重啟一下docker服務(wù)，檢測一下sock路徑是否正確。5、在實際使用中，docker獲取遠(yuǎn)程鏡像，報錯信息和截圖如下get https:/registry-1.docker.io/v2/: dialtcp: lookup registry-1.docker.io該錯誤表示無法連接到遠(yuǎn)程倉庫docker.io。解決方案如下，查看本地是否配置dns，能否ping通到dicker.io，如果能夠ping通，但是下載速度也是非常慢，可以修改docker倉庫源為國內(nèi)或自建的倉庫源。docker進(jìn)行修改方法為，對vim /etc/docker/daemon.json，執(zhí)行如下命令：6、容器啟動過程中，有下列報錯，具體報錯信息如下。/usr/bin/docker-current: error response from daemon: oci runtimeerror:container_linux.go:247: starting container process caused