我們從今年6月開始在生產環境進行 docker 容器化部署，將已經遷移至 ASP.NET Core 的站點部署到 docker swarm 集群上。開始我們選用的阿里云容器服務，但是在使用過程中我們遭遇了恐怖的路由服務（acsrouting）路由錯亂問題 —— 請求被隨機路由到集群中的任一容器，雖然后來阿里云修復了這個問題，但我們對容器服務失去了信心，走上了用阿里云服務器自建 docker swarm 集群的道路。
用上自建 docker swarm 集群之后，本以為可以在云上容器中過上安穩的日子。哪知卻遭遇了另外一個奇怪的問題，docker swarm 集群部分節點經常無故宕機，只有通過阿里云控制臺重啟服務器后才可以恢復（有時需要重新加入集群），有時節點宕機嚴重就會造成整個集群掛掉。之前，集群掛掉時立即重建集群可以立馬恢復（相比容器服務，可以很快地重建集群是自建 docker swarm 的優勢之一），但昨天用5臺服務器中的3臺重建集群，上去后又掛了，后來用剩下的2臺重建集群才恢復正常。
昨天的集群掛讓人越想越覺得蹊蹺，當時未進行任何部署操作，負載也不高，重建集群為什么那3臺繼續掛，這2臺可以正常運行？唯一可以懷疑的地方只有這5臺服務器是共享計算型 n1 服務器，可能是當時某種資源爭搶情況引起的。于是，我們另外買了3臺獨享型服務器創建集群，結果遇到了之前從未遇到過的 docker swarm 問題，用這3臺或者其中2臺服務器，無論我們怎么創建集群，docker swarm 的 routing mesh 始終不能正常工作 —— 所部署的服務指定了 publish port ，但容器啟動后，只能在運行該容器的節點上訪問該端口，在其他節點上無法訪問，而用同樣的配置在之前用的共享型服務器上部署卻沒有這個問題。太奇怪了！
對于這個太奇怪的問題，實在無從下手，只能向阿里云提交工單。。。
終于從阿里云那里知道了真相：原來 docker 與阿里云服務器存在兼容問題。阿里云建議的解決方案是：使用他們的容器服務。
如果我們早點知道這個真相，就不用這么折騰了，寫這篇隨筆就是想告訴大家 —— 由于 docker swarm 與阿里云服務器存在兼容問題，在這個問題沒有解決之前，在阿里云上不要用自建 docker swarm 集群跑生產環境（后來獲知只在經典網絡下才有這個問題，VPC網絡下沒這個問題）。
文章列表
留言列表
