云计算之路-阿里云上-2017年最错误的选择： 生产环境使用 docker swarm

2017年12月29日 10:18 ~ 11:00 左右，由于整个 docker swarm 集群宕机，造成我们迁移至 .net core 跑在 docker swram 上的所有站点无法正常访问，由此给您带来很大很大的麻烦，请您谅解。受这次故障影响的站点有 闪存，博问，班级，园子，短信息，招聘，小组，openapi ...

2017年，随着将一个一个项目从 .net framework 迁移至 .net core ，我们兴奋地在部署上迈出了重要的一步——终于可以进行 docker 部署了。对于 docker 集群的选型，我们最终选择了 docker swarm ，因为 docker swarm 的简单，因为 docker swarm 与 docker 结合的天衣无缝，因为 docker swarm 已经经历了多年的磨练与发展，因为阿里云对 docker 支持的与时俱进，我们想应该不会有什么大坑。

但是，我们错了，大错特错。一次一次的 docker swarm 集群的不稳定让我们痛苦不堪，不管是开发环境，还是生产环境，有时少数节点宕机，有时多数节点宕机造成整个集群宕机，有时节点看似正常而实际节点的overlay网络无法进行正常通信。。。当出现节点宕机时，多数情况下通过阿里云控制台1次或多次重启服务器可以恢复正常，但有时多数 manager 节点出现宕机，重启后集群无法恢复，只有重建整个集群，我们今天遇到的故障就属于这种情况。

从我们一次次遇到的生产集群宕机情况看，宕机发生的概率可能与集群中节点的持续运行时间有关，当我们将集群中的所有节点通过阿里云控制台重启后的一段时间内，不会出现宕机问题。这次故障是发生在集群持续运行25天之后。接下来，我们会每隔2周重启一下集群中的所有节点，看是否还会出现节点宕机的问题。

我们的 docker swarm 集群节点使用了 5 台阿里云 2 核 4 G的独享服务器（VPC网络），3 个 manager 节点，2 个 worker 节点，运行的容器在 50 个之内，docker 版本是 Docker version 17.10.0-ce, build f4ffd25 。

我们真的不知道这是 docker swarm 的问题，还是阿里云的问题，但是我们知道这是我们选择的问题，我们要为我们的选择负责，想尽一切办法避免再次出现整个集群宕机的问题。再次请大家谅解这次故障给您带来的麻烦。