我们从今年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网络下没这个问题）。