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

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

2、為兩步：首先使用標準的遠程登錄工具登錄到docker宿主機上，然后使用docker exec進入指定的、運行中的容器進程命名空間中，作為調試應用的一種手段，這是最直接而且有效的。下面我們舉一個例子，對運行haproxy的Docker容器進行故障檢測、排除和調試。我們先創(chuàng)建haproxy的配置文件haproxy.cfg。使用官方推薦的haproxy docker鏡像和創(chuàng)建的配置，運行該容器。在docker宿主機上，運行以下命令來啟動該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)在進入檢查容器并調試階段。具體案例如下，如果確認haproxy容器是否在監(jiān)聽80端口，ss程序可以在絕大多數(shù)的liunux發(fā)行版上打印出套接字統(tǒng)計信息的小結。可以運行以下命令，來顯示docker容器內正在監(jiān)聽的套接字的統(tǒng)計信息。dockerhost$ docker exec haproxy /bin/ss l由于ss已經在haproxy：1.5.14的父容器linux:jessie中默認安裝了，所以docker exec這種方法才能起到作用。我們不能使用類似于netstat的工具，因為它默認沒有被安裝，運行n

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

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

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

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

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

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

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

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

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

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

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

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

16、ux容器，通過復制流行的docker容器根文件系統(tǒng)，可以安裝任意一款工具而不會污染宿主機的文件系統(tǒng)。3. 容器的常見故障舉例在實際的使用中，除了上述的網絡、磁盤因素外，還有各種各樣的故障，一般有三類。應用故障：應用的執(zhí)行狀態(tài)和預期的不一致；容器故障：無法正確的創(chuàng)建、停止、更新容器；集群故障：集群創(chuàng)建失敗、更新失敗和無法連接。以下會舉一些常見的案例來進行說明。1、在生產環(huá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命令查看容器啟動的詳細日志，發(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)解決方案一般有兩種，關閉宿主機selinux配置文件，/etc/selinux/config，將配置文件中enforcing設置為disabled，然后重啟系統(tǒng)，然后重啟docker引擎即可。關閉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無法找到當前的group組信息，docker組有可能被誤操作刪除，一般解決方法有兩種。方法一創(chuàng)建宿主機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設備提供至docker使用，解決方法為創(chuàng)建更多的loopback設備，具體命令如下。for i inseq 0 6;do mknod -m 0660 /dev/loop$i b 7 $i;done4、在實際使用中，對docker進行操作，當執(zhí)行docker命令時，有如下報錯。cannot connect to the docker daemon at unix:/var/run/docker.sock. is the docker daemon running?該報錯提示docker容器沒有被正常啟動解決方法如下，首先檢測docker進程是否正常啟動，

21、可以通過ps -ef|grep docker，如果沒有啟動，啟動docker即可。檢測docker進程存在，但是無法連接，可以重啟一下docker服務，檢測一下sock路徑是否正確。5、在實際使用中，docker獲取遠程鏡像，報錯信息和截圖如下get https:/registry-1.docker.io/v2/: dialtcp: lookup registry-1.docker.io該錯誤表示無法連接到遠程倉庫docker.io。解決方案如下，查看本地是否配置dns，能否ping通到dicker.io，如果能夠ping通，但是下載速度也是非常慢，可以修改docker倉庫源為國內或自建的倉庫源。docker進行修改方法為，對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