一、背景

一般需要對外提供服務的Docker容器，我們在啟動時后使用-p命令將對外訪問端口暴露給外部，例如啟動Docker Registry，我們將5000端口映射出來供外部訪問：

docker run -d -p 5000:5000 registry

但最近碰到一個非常奇怪的情況：研發組里一個CentOS 7測試環境里部署有Docker Registry，并對外暴露了端口。啟動容器后一段時間內都是可以正常工作的，但在不定時間間隔后，外部主機就會出現無法從倉庫中拉取鏡像的情況，提示TimeOut：

然而在Docker宿主機上訪問倉庫則可以正常訪問：

至于這個問題，只有手動重啟出問題的Docker daemon服務后，外部才可以重新訪問，但只要再過一段時間又會出現這樣的問題。

二、問題排查

碰到這個問題我第一反應就是問組里的人，是不是有人重啟過CentOS 7 自己的firewallD了。

因為這臺服務器是我配置的，防火墻雖然開著但我已經開啟端口訪問了，所以肯定不是因為防火墻阻斷連接的緣故。但由于這篇文章是篇踩坑排查文檔，所以還是把這種情況寫出來了

情況一：開著防火墻但沒有開放端口

CentOS 7自帶并啟用了防火墻FirewallD，我們可以通過下面的命令檢查FirewallD的狀態：

firewall-cmd --state

如果輸出的是“not running”則FirewallD沒有在運行，且所有的防護策略都沒有啟動，那么可以排除防火墻阻斷連接的情況了。

如果輸出的是“running”，表示當前FirewallD正在運行，需要再輸入下面的命令查看現在開放了哪些端口和服務：

firewall-cmd --list-portsfirewall-cmd --list-services

可以看到當前防火墻只開放了80/tcp端口、ssh服務（22/tcp）和dhcpv6-client服務，并沒有打開Docker容器映射的5000/tcp端口。

解決方案有兩種：

1.關閉FirewallD服務：

如果您不需要防火墻，那直接關掉FirewallD服務就好了

systemctl stop firewalld.service

2.添加策略對外打開指定的端口：

比如我們現在要打開對外5000/tcp端口，可以使用下面的命令：

firewall-cmd --add-port=5000/tcp --permanentfirewall-cmd --reload

如果只是臨時打開端口，去掉第一行命令中的“--permanent”參數，那么當再次重啟FirewallD服務時，本策略將失效。 

情況二：人為重啟CentOS 7的FirewallD服務

FirewallD是CentOS系統在7版本引入的新組件，簡單的說就是iptables的包裝，用于簡化防火墻相關的設置。

然而FirewallD和Docker相處的并不是特別好，當FirewallD啟動（或重新啟動）時，會從iptables中刪除DOCKER鏈，造成Docker不能正常工作：

FirewallD

CentOS-7 introduced firewalld, which is a wrapper around iptables and can conflict with Docker.

When firewalld is started or restarted it will remove the DOCKER chain from iptables, preventing Docker from working properly.

When using Systemd, firewalld is started before Docker, but if you start or restart firewalld after Docker, you will have to restart the Docker daemon.

 摘自Docker官方文檔《CentOS - Docker Documentation》

在CentOS 7中，如果設置使用systemd開機自啟動Docker服務是不會有問題的，因為Docker在systemd配置文件中明確注明了“After= firewalld.service”，以保證Docker daemon 在FirewallD啟動后再啟動。

（Docker：惹不起我還躲不起嗎）

但每當用戶手動重啟過FirewallD服務之后，FirewallD服務會將Docker daemon寫入iptables的DOCKER鏈刪除，所以需要手動重新啟動一次Docker daemon服務，讓Docker daemon服務重建DOCKER鏈。

 不過問了組里另外兩個研發，都說沒有動過。查看了shell的history也沒找到對應的記錄。

這就很奇怪了。不過經過一段時間的蹲點排查之后，我終于發現了一個新的原因：

情況三：沒有啟用IP_FORWARD

因為一直沒法定位出問題的所在，所以我們研發組都是發現不能正常訪問倉庫時，手動登陸宿主機重啟Docker daemon服務。

在有一次登錄到宿主服務器上準備重啟Docker daemon服務前，我突然想起之前在用Docker的時候還碰到過另一個問題：如果宿主機沒有啟用IP_FORWARD功能，那Docker容器在啟動時會輸出一條警告消息：

WARNING: IPv4 forwarding is disabled. Networking will not work.

并且將不能在啟動的容器中訪問外部網絡，容器對外暴露的端口外部也不能正常訪問：

會不會是因為宿主機的IP_FORWARD功能沒有啟用所以才引起的這個故障呢？

sysctl net.ipv4.ip_forward

果然，輸出表示當前系統的IP_FORWARD功能處于停用狀態！

可是問題來了，當時啟動容器的時候都是好的啊，什么都沒有輸出，怎么用著用著IP_FORWARD功能就被禁用了呢？

等等，Docker daemon服務在啟動的時候會自動設置iptables設置，難不成它還會檢查IP_FORWARD設置，并幫我臨時啟用嗎？

帶著這個假設，我手動重啟了一下Docker daemon服務：

果然，Docker daemon服務在啟動過程中會檢查系統的IP_FORWARD配置項，如果當前系統的IP_FORWARD功能處于停用狀態，會幫我們臨時啟用IP_FORWARD功能，然而臨時啟用的IP_FORWARD功能會因為其他各種各樣的原因失效…

雖然具體造成本次故障的原因現在還沒有確鑿的證據定位出，但我現在嚴重懷疑是因為重啟網絡服務造成的。因為出問題的服務器宿主機上運行著我們研發組正在開發的Web項目，其中有一個功能是修改網卡IP地址，這個功能在修改完網卡IP后，會自動調用下面的命令重啟網絡服務：

systemctl restart network.service

而重啟網絡服務正會使Docker daemon服務自動設置的臨時啟用IP_FORWARD配置失效：

另外因為是程序直接調用命令，所以不會在history命令中留下痕跡。

至于修復方案倒非常簡單，只要一行命令就可以了：

echo 'net.ipv4.ip_forward = 1' >> /usr/lib/sysctl.d/50-default.conf

執行完成后，重啟服務器或使用下面的命令從文件中加載配置：

sysctl -p /usr/lib/sysctl.d/50-default.conf

就可以了。

三、小結

Docker daemon服務在啟動的時候會幫幫我們調整很多的配置項，比如這次出事兒的IP_FORWARD配置。

Docker daemon啟用IP_FORWARD功能是因為Docker容器默認的網絡模式（bridge/網橋模式）會給每個容器分配一個私有IP，如果容器需要和外部通信，就需要使用到NAT。NAT需要IP_FORWARD功能支持，否則無法使用。這也解釋了為什么會出現在IP_FORWARD功能停用的情況下，使用bridge模式的容器內外均無法訪問的情況。

只是在Linux下，出于安全考慮，默認是停用IP_FORWARD功能的，Docker daemon服務在啟動時會檢查IP_FORWARD功能是否已經啟用，如果沒有啟用的話，Docker daemon會悄無聲息的臨時啟用此功能，然而臨時啟用的IP_FORWARD功能并不能持久化，會因為其他命令的干擾導致失效。

不過這次的事情告訴了我一個小道理：當出現問題的時候，不要慌，要結合經驗大膽的做出假設并驗證，治標治本。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網的支持。