摘要：后端接口沒問題，前端訪問出錯(cuò)了，見鬼了有種預(yù)感是容器的特性導(dǎo)致的問題。日志居然直接連接到標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯(cuò)誤。。。男人的直覺告訴我有貓膩重啟下容器的，然而容器也被重啟了。。。感覺應(yīng)該是內(nèi)部域名解析緩存問題。

業(yè)務(wù)架構(gòu)：

部署細(xì)節(jié)：
　　兩容器均部署在同一機(jī)器上，通過 docker-compose 編排，并且通過link方式鏈接。

在有次更新代碼時(shí)，發(fā)現(xiàn)前端能夠打開，但是所有接口請求全是502(Bad GateWay)

查看前端容器compose_ui_1的日志，刷了一大波502(Bad GateWay)

UI沒問題的話，第一反映就是 compose_api_1 跪了，所以直接去容器看看日志

容器日志看起來很正常，沒有崩潰，而且這個(gè)日志就好像從來沒收到請求那樣，但是很明顯我前端肯定有訪問的，感覺很奇怪。將接口取出來多帶帶訪問試試看：

接口多帶帶訪問結(jié)果還是很殘暴的502(Bad GateWay)，感覺還是不太可信，是不是端口或者主機(jī)什么訪問錯(cuò)誤了？
本機(jī)開啟 wireshark 抓包確認(rèn)下請求的主機(jī)和端口：

這樣就很確保前端compose_ui_1訪問的主機(jī)和端口是正確的，而且確切結(jié)果是502(Bad GateWay)，這樣只能從compose_api_1下手排查了。

之前也是遇到相似的問題，因?yàn)?b>compose_api_1是通過uwsgi部署的python flask，那會(huì)總是用法覺得有點(diǎn)問題，改過uwsgi配置之后消停了一會(huì)?，F(xiàn)在又卷土重來了。

先判斷下compose_api_1是不是真的跪了。。。雖然對這個(gè)沒抱什么希望。。。

直接訪問 后端api 接口

額。。。尷尬。。。仿佛冤枉錯(cuò)好人了。這不對吧，抓包看看再次確認(rèn)下先：

仿佛真的是。。。再 see see 容器日志：

額。。。好吧。。。我錯(cuò)了，compose_api_1沒跪。

于是問題來了。。。后端接口沒問題，前端訪問出錯(cuò)了，見鬼了？

有種預(yù)感是容器的特性導(dǎo)致的問題。但愿不要。。

先進(jìn)去compose_ui_1容器抓包分析下，看看整個(gè)請求鏈有沒有問題：

似乎發(fā)現(xiàn)了點(diǎn)貓膩，Flags[R.]是代表 tcp鏈接 被 reset 重置 了，但是為什么平白無故重置呢？

看到 172.17.0.5.8080 返回的, 先 telnet 問問先：

What？？？這就很迷了，首先這個(gè) 172.17.0.5.8080 哪來的呢？其次就是為毛端口不通？

突然想到一個(gè)很重要的問題：

容器之間是怎么知道它要把請求發(fā)給誰呢 ？

在前面已經(jīng)交代過，這兩個(gè)容器是通過 link 的方式鏈接的，像下面這樣：

谷歌搜了下 link 工作原理：

link機(jī)制通過環(huán)境變量的方式提供了這些信息，除此之外像db的密碼這些信息也會(huì)通過環(huán)境變量提供，docker將source container中定義的環(huán)境變量全部導(dǎo)入到received container中，在received container中可以通過環(huán)境變量來獲取連接信息。

使用了link機(jī)制后，可以通過指定的名字來和目標(biāo)容器通信，這其實(shí)是通過給/etc/hosts中加入名稱和IP的解析關(guān)系來實(shí)現(xiàn)的

所以就是說在 compose_ui_1 的 根據(jù)指定的名字并在 /etc/hosts 翻譯出具體的ip然后進(jìn)行通信咯？
看看容器的名字是啥？

compose_ui_1 的 /etc/hosts

root@e23430ed1ed7:/# cat /etc/hosts
127.0.0.1    localhost
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet
ff00::0    ip6-mcastprefix
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
172.17.0.4    detectapi fc1537d83fdf compose_api_1
172.17.0.3    authapi ff83f8e3adf2 compose_authapi_1
172.17.0.3    authapi_1 ff83f8e3adf2 compose_authapi_1
172.17.0.3    compose_authapi_1 ff83f8e3adf2
172.17.0.4    api_1 fc1537d83fdf compose_api_1
172.17.0.4    compose_api_1 fc1537d83fdf
172.17.0.6    e23430ed1ed7

如果真是按照資料所說，那 172.17.0.4:8080 才是 compose_api_1 的地址隱射才對吧？，試下先

雖然返回了 auth product is None，但其實(shí)這是有效的請求。

再看看 compose_api_1 容器的日志：

所以基本沒跑了， 為什么前端訪問直接就是 502， 原因就是 ui容器向錯(cuò)誤的地址發(fā)送請求了

那么為什么會(huì)這樣呢？平白無故抽風(fēng)了？

剛才根據(jù) host 的記錄實(shí)驗(yàn)了，按照它的映地址發(fā)起接口請求，是沒有問題的：

查看下 compose_ui_1 的 nginx 日志

尷尬。。。 nginx 日志居然直接連接到標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯(cuò)誤。。。
那為了簡單點(diǎn)，還是直接用 docker logs 查看吧

看來 nginx 的轉(zhuǎn)發(fā)已經(jīng)是錯(cuò)誤的，為什么會(huì)轉(zhuǎn)發(fā)到 172.17.0.5， 看看 nginx 關(guān)于轉(zhuǎn)發(fā)的配置：

這個(gè) detectapi 和 上面貼出的 hosts 表能找到正確的地址 172.17.0.4 呀？搞不明白為什么會(huì)轉(zhuǎn)發(fā)到 172.17.0.5

難道是系統(tǒng)的域名解析錯(cuò)誤了？

尼瑪這真是太神奇了。

男人的直覺告訴我 nginx 有貓膩！

重啟下容器的 nginx，然而容器也被重啟了。。。

再訪問頁面，居然可以了。。。

再看看容器的nginx日志，已經(jīng)轉(zhuǎn)發(fā)成功了

這樣子的話，其實(shí)應(yīng)該能定位到，問題是出在了 nginx 上面？

只是為什么 nginx 會(huì)有這樣的錯(cuò)誤呢？不太應(yīng)該呀。。 感覺應(yīng)該是 nginx 內(nèi)部域名解析緩存問題。

然后查了下資料，呵呵，還真有。https://www.zhihu.com/questio...

這就非常尷尬了。對這個(gè)問題抱有點(diǎn)懷疑，咨詢了資深大佬，然后大佬的回復(fù)就是:

如果 proxy_pass 后面跟的域名的話，在 nginx 啟動(dòng)的時(shí)候就會(huì)初始化好，以后就只會(huì)復(fù)用這個(gè)值；參考：ngx_http_upstream_init_round_robin 函數(shù)
如果 proxy_pass 后面跟的是upstream，配置才會(huì)走解析和緩存的邏輯；

不直接 proxy_pass 真實(shí)域名，而是轉(zhuǎn)發(fā)到 upstream 配置；

也可參考剛才的知乎鏈接處理方案：https://www.zhihu.com/questio...；

為什么 compose_ui_1 指定的 compose_api_1 會(huì)出錯(cuò)？

proxy_pass 如果后面跟真實(shí)域名，是真的直接復(fù)用還是有時(shí)間緩存？

本來想用 gdb 調(diào)試下這個(gè)問題，然而花了一天時(shí)間，毛都沒有。不過也有點(diǎn)小收獲，那就是如何配置nginx來支持gdb：

1.修改編譯配置文件：auto/cc/conf

ngx_compile_opt="-c"  改成 ngx_compile_opt="-c -g"

2../configure 時(shí)，增加編譯參數(shù)：--with-cc-opt="-O0", 避免編譯器優(yōu)化；
例如：./configure --prefix=/usr/local/nginx --with-cc-opt="-O0" ....
如果不這樣的話，編譯器會(huì)優(yōu)化代碼，導(dǎo)致調(diào)試過程中，循環(huán)中的一些變量值無法打印，會(huì)報(bào)下面的錯(cuò)誤：

value optimized out

下面可以看下調(diào)試的效果：
nginx worker process 處理入口：ngx_http_static_handler

歡迎各位大神指點(diǎn)交流, QQ討論群: 258498217
轉(zhuǎn)載請注明來源: https://segmentfault.com/a/11...