我们从今年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 与阿里云服务器存在兼容问题,在这个问题没有解决之前,在阿里云上不要用自建 docker swarm 集群跑生产环境。