.NetCore&Linux&Docker&Portainer踩坑歷險記

最近有一個雲伺服器和資料庫的遷移任務，踩坑爬坑無數次，覺得必須要記錄一下。大家瓜子花生準備好，聽我慢慢講故事#手動笑哭#。

故事背景

公司是做電商業務的，在天貓有幾家旗艦店資料量也很大。阿裡有一個稱為聚石塔的平臺，專門給這些ISV提供各種雲資源，強制系結了一些業務，原本我們在聚石塔中有一臺ECS和一臺RDS部署在華東杭州節點，本月初突然收到阿裡的郵件說是要整體遷移到張北節點，華東節點將會在9月底全部停止服務，並附帶發了一份遷移檔案，要我們儘快遷移。好在我們用到的資源不多，最初覺得遷移過程並不會太複雜，實際還是太天真了。像我這樣只有一臺伺服器和一臺資料庫的使用者遷移過程都謂之艱辛，對於那些有幾十甚至上百實體的ISV，那真是欲哭無淚了。每天看著遷移群裡大家的各種吐槽、抱怨、焦急、無可奈何，還有那幾位一整天都在被艾特的阿裡技術支援，說起來都是淚。

於是接下來制定好遷移計劃，發郵件購買要用到的資源，等過了兩天東西到位，就擼起袖子開幹了。

忘了說了，這些東西原先是由另外一位同事負責，然而年後他就開溜了，上級指示我扛過大旗（guo）。

開胃菜

我們的RDS是SQL Server 08 R2版本，阿裡在遷移通知中專門提到了這個產品，而且用到了重要提示字樣，大意是說微軟已經對這個版本的資料庫停止了安全更新，所以張北節點已經不再售賣這個版本的實體，要先在當前節點完成版本升級後再遷移。看了下他的遷移手冊，覺得異常複雜和危險重重，於是果斷放棄官方方案，決定在張北節點買好2016版本資料庫，直接切換資料推送，後來找阿裡的技術支援諮詢了這個方案，也表示可以執行。當然了，我能這樣做是有一個前提的，我們的這個庫是隻讀庫，用來接收阿裡的資料推送然後給業務系統查詢，可以理解為只是一個過渡不儲存實際的業務資料，對安全性要求不高，就算丟失也能透過淘寶開放平臺的API去查詢。如果是業務庫，那就只能老老實實的按官方檔案摸著石頭過河了，看群裡的反饋，這道開胃菜不好吃，我也算是幸運跳過了第一個坑。

初進坑

RDS處理完畢，那就著手開始折騰伺服器，這是一臺Linux的機器，系統是Centos7，主要跑了3個服務：上文提到的RDS資料查詢API（一個dotnetcore2.1的程式）、Rabbitmq實體和它的管理工具、Portainer，由Docker統一管理，而Docker又由Portainer來管理。按照官方檔案，先在原伺服器上建立映象，經過漫長的等待（大概40分鐘吧，有的人反映等了大半天最後生成失敗的，心態崩…），然後把映象複製到張北節點，然後透過映象生成實體，按理說新機器和原機器是完全一樣的，各項服務都應該執行正常，並且專門找技術支援確認了，可實際真的不是這樣。

聚石塔的伺服器只開放30001-30005這幾個埠，於是嘗試訪問一下Portainer所在的30003埠。瀏覽器輸入地址再回車，等了幾十秒後顯示超時無法訪問，一臉懵逼。Ping了一下伺服器IP，沒毛病，又登入伺服器檢視docker和container的執行狀態以及埠對映，都沒問題，又檢視埠監聽和防火牆，還是正常，二臉懵逼。

查一下container的日誌，提示執行正常，三臉懵逼。

我的招已經用完了，沒辦法轉向群裡諮詢技術支援，回覆說這幾個埠要走工單申請開通，WTF……老實寫工單提交再到群裡艾特幫忙快點處理，又陷入漫長的等待中，當時大概2點鐘的樣子。下午5點多工單狀態更新了說正在轉給技術處理請耐心等待，然後，就沒有然後了接著等，到7點還是沒訊息決定先下班。

第二天上班發現還是沒有訊息，又去群裡艾特技術支援，幾分鐘後回覆叫我去給ECS系結一個安全組，照做後再次訪問30003埠依然不行，長嘆一口氣。又嘗試訪問了一下webapi所在的30001埠，神奇般的成功了#手動黑人問號臉#。諮詢了公司運維，教我幾個命令簡單排查了下，後來因為太忙沒回覆我了，後來又一頓百度谷歌無果，陷入僵局。心理暗自把這個鍋丟給了阿裡，覺得是他們哪裡配置有問題。

事情不能就這樣僵著啊，Portainer起不來程式不能更新，於是打算直接在宿主機上跑一下修改後的dotnetcore程式看資料庫訪問是否正常。按照微軟檔案安裝對應版本的SDK：

安裝好後把釋出檔案上傳到伺服器，然後用dotnet命令啟動了程式，一切正常。訪問我的測試入口：

Curl http://locahost:5000/api/values/testdb/123

看到傳回了資料庫的測試資料，信心重拾。回過頭重新折騰docker，發現docker死活起不來了，囧：

　　

拿著錯誤資訊又是一頓百度谷歌，不斷的照網上改配置重啟系統，幾個小時過去依然不行，決定解除安裝docker重灌。於是依次執行：

yum remove docker*
reboot
yum install docker
docker version
systemctl start docker

然而啟動的時候問題依舊，又是長嘆一口氣。仔細回想了一下，只有yum update對系統做了大的改動，難道是這個問題麼？不知不覺又到了晚上7點多，腦子懵的很決定先下班第二天接著搞。

真所謂一波未平一波又起。

再進坑

早上到公司和微信群的小夥伴吐糟著遭遇，大家勸我重灌系統，我一邊發著捂臉笑哭的表情，一邊默默地上聚石塔後臺點了磁碟初始化，docker啟動不了的問題就算翻篇了，一切從頭再來。

依然還是埠的問題，實在沒轍了只有給阿裡提工單問為什麼埠不通，阿裡工程師先後叫我排查了iptables、埠監聽情況、清除iptables等等還是不行，最後要了我的伺服器賬號上去排查，在工單中看到阿裡的工程師晚上11點多還在幫我排查問題，也真不容易。

終於，在阿裡後面的回覆中事情迎來了轉機，給了我非常大的提示：

從中我捕捉到了2個重要資訊，一個是容器的IP，一個是路由解析問題。我馬上百度如何查容器的IP地址，然後試著去ping容器的IP，發現30001埠系結的容器（172.22.0網段）正常，30003埠系結的容器（192.168.0網段）無法訪問，那麼這就說明是宿主機和容器網路不通導致的問題。又查看了系統的路由表：

這個路由表有個奇怪的現象，就是192.168.0這個網段指向了2個不同的網絡卡，分別是eth0和docker0。我知道，eth0是宿主機預設的閘道器，docker0是docker啟動時自動建立的虛擬閘道器，但是還不清楚這樣的配置會有什麼影響，於是百度了一下Linux路由的詳細介紹，得知相同的配置會有優先順序的問題，又嘗試著刪除eth0的配置：

1	route del -net 192.168.0.0 netmask 255.255.255.0

再次用公網訪問30003埠，成功了！！！終於看到了熟悉的頁面：

沒那麼簡單

以為事情就此告一段落後面都是平坦大道，想不到問題又來了。透過docker run我新映象後發現容器總是自動退出，於是尋找各種讓容器持續執行的辦法，一陣折騰沒有效果，去微信群問小夥伴，問我是不是程式拋異常了，我頓時一種柳暗花明的感覺，立馬檢視容器日誌：

果然是報錯了：

很顯然，是說我的framework版本不對，但是我的dockerfile中確實引入的2.1版本執行時：

FROM microsoft/dotnet:2.1-runtime
COPY . /app
WORKDIR /app
EXPOSE 5000 80
ENTRYPOINT ["dotnet", "DRP.API.dll"]

退一萬步說，宿主機我也已經安裝過SDK，而且直接在宿主機上執行都是可以的，為什麼透過docker來執行就掛了，百思不得解。只能按照提示中的資訊排查是不是少裝了什麼元件，一陣yum install下來還是失敗：

去廣州微軟.net俱樂部的微信群請教別人，兩位大佬給我分析解答了一下，一位說是我的dockerfile在copy檔案時漏了一些取用檔案，要我重新修改dockerfile，不過經過多次調整測試依然無效，不得不採用第二位的辦法，就是把執行時改為2.2版本：

修改dockerfile為如下內容：

# 新增基礎映象
FROM microsoft/dotnet:2.2-aspnetcore-runtime

#容器中系統的工作空間
WORKDIR /app

#複製當前檔案夾下的檔案到容器中系統的工作空間
COPY . /app

#設定Docker容器對外暴露的埠
EXPOSE 5000 80

#執行應用程式
ENTRYPOINT ["dotnet", "DRP.API.dll"]

重新打包映象，然後run起來，這次一切都是那麼的自然，docker ps檢視容器已經狀態是up了。欣喜若狂，以為即將看到勝利的曙光，接著用瀏覽器開啟我的測試入口：

http://xxx.xxx.xxx.xxx:30001/api/values/testdb/123

尷尬的報了500，心中萬馬奔騰….

這次學機靈了，第一時間docker logs，發現是資料庫報錯了：

fail: Microsoft.AspNetCore.Server.Kestrel[13]
      => ConnectionId:0HLM4DDINAGJC => RequestId:0HLM4DDINAGJC:00000001 RequestPath:/api/values/testdb/123
      Connection id "0HLM4DDINAGJC", Request id "0HLM4DDINAGJC:00000001": An unhandled exception was thrown by the application.
SqlSugar.UtilExceptions: English Message : Connection open error . A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)
Chinese Message :  連線資料庫過程中發生錯誤，檢查伺服器是否正常連線字串是否正確，實在找不到原因請先Google錯誤資訊：A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server).
   at SqlSugar.AdoProvider.GetDataReader(String sql, SugarParameter[] parameters)
   at SqlSugar.QueryableProvider`1.GetData[TResult](KeyValuePair`2 sqlObj)
   at SqlSugar.QueryableProvider`1._ToList[TResult]()

很明顯是資料庫連線不上，檢查連線字串，沒毛病，再次進入僵局。

正在苦惱時，突然想起前面刪掉的那條路由，嘗試重啟網路恢復路由：

再次訪問測試地址，確實成功了。可問題又進入了死迴圈，容器內的應用無法訪問。

終見天日

經過以上的種種分析後，最終把問題定在了路由這兒。既然是因為同一網段有2個閘道器，那麼我修改一下docker的預設網段不就可以了嗎？再次面向百度程式設計，得到兩種方案：

第一種方案，建立新的的閘道器和路由，然後分配給docker：

service docker stop

ip addr add 192.168.1.1/24 dev bridge0
ip link set dev bridge0 up

vim /etc/docker/daemon.json

加上“bridge”: “bridge0”節點並儲存退出，再重啟docker：

第二種方案，直接修改docker0的預設網段：

service docker stop

vim /etc/docker/daemon.json

加上“bip”: “192.168.1.1/24”節點並儲存退出，再重啟docker即可。

我這裡採用第二種方式，修改後的路由表為：

重新訪問各種服務，全部都正常執行，到此總算是撥開雲霧見青天。

有個小細節不知大家是否發現，也是我當時存在的一個疑惑，就是前面有提過兩個容器的網段不一樣，按理說透過docker run來的容器應該都是相同的網段，為什麼會這樣呢？後來在折騰Portainer的時候找到了這個問題。

Portainer是一款docker管理工具，簡而言之的說就是把用命令操作的東西視覺化，當然功能遠不止這些。Portainer中有一個Stack功能，我並不清楚這是乾什麼用的，只是看到舊的Portainer中的容器系結了一個stack所以想依葫蘆畫瓢也搞一個：

於是拿stack的配置檔案新建立一個，沒想到居然報錯，提示已存在相同名稱的容器。我馬上意識到這個特殊的容器應該是透過stack建立，我刪掉已存在的容器再次建立stack，這次成功了。出於好奇，仔細分析了stack的配置檔案：

發現裡面主要是定義了映象名、容器名、網路樣式、埠對映這些，而其中vhnet這個網路配置讓我很感興趣，轉而檢視docker已經配置好的閘道器：

看到這裡，一種恍然大悟的感覺，你懂的。

除此之外，從前任留下的檔案裡可以知道，stack有一種類似熱更新的功能，修改配置檔案中的映象名後update stack就能實現對應的容器更新，不用起新的容器，這點確實很不錯。更多強大的功能日後也會慢慢學習。

我的收穫

經過前面幾天的折騰，我更加熟悉了docker的各種基本操作和配置，也學會了使用新的命令，像docker inspect檢視容器資訊、docker attach進入容器內部，也加深了在Linux上排查問題的思路理解，學到了新的操作命令。也實際使用docker在Linux上部署了一次dotnetcore的生產環境，收穫頗豐。

遺留的問題

1、     yum update後到底經歷了什麼讓docker跪地不起，報錯原因至今沒搞明白。

2、    為什麼2.1的dotnetcore程式在2.1執行時跑不起來，換成2.2版本就可以。

3、stack是怎麼實現修改映象後容器就能生效的呢？

有知道的大佬還請多多指導。

總結

錶面上全篇都在講才踩坑的事，但追根究底還是因為自己在Linux方面的知識欠缺和經驗不足。還是那句話，多踩坑，會讓你記憶深刻，會讓你學到意想不到的東西，會讓你的身體變得足夠大，下次碰到坑能一腳踏過去。