Docker容器中模拟RabbitMQ连接故障的可行方案咨询

刚好碰到过类似的调试需求，给你几个针对Alpine镜像RabbitMQ容器的实用方案，不用再纠结容器内权限不足的问题：

• 从宿主机直接断开容器网络连接（最推荐）
  不用进入RabbitMQ容器，直接在宿主机用Docker命令断开它和Compose网络的连接：

  docker network disconnect <你的Compose网络名称> <RabbitMQ容器名称>
  

  这个操作权限是宿主机的root，完全不会有Permission denied的问题。想要恢复连接的话，执行：

  docker network connect <你的Compose网络名称> <RabbitMQ容器名称>
  

  优点是操作简单，不用修改容器内任何东西，能精准模拟网络断开的场景。

• 在容器内用tc命令模拟100%丢包（需临时安装工具）
  Alpine默认没有tc，但可以快速安装iproute2包：

  apk add iproute2
  

  然后执行命令让eth0网卡丢所有包：

  tc qdisc add dev eth0 root netem loss 100%
  

  这样应用发起的所有连接请求都会被丢弃，完美模拟严重网络故障。恢复的话执行：

  tc qdisc del dev eth0 root netem
  

  注意：这个操作需要容器内有root权限，如果你的容器是用非root用户运行的，可能需要先切换到root（su root，如果镜像允许的话）。

• 在应用容器侧拦截连接请求
  不用动RabbitMQ容器，直接在你的应用容器里修改hosts文件，把RabbitMQ的服务名指向一个无效IP：

  echo "192.168.99.99 rabbitmq" >> /etc/hosts
  

  这样应用会尝试连接不存在的IP，自然触发连接故障。恢复的话删掉这条hosts记录即可。
  这个方案的好处是不需要触碰RabbitMQ容器，适合只想测试应用侧容错逻辑的场景。

• 临时停止RabbitMQ容器（极端场景模拟）
  如果需要模拟RabbitMQ服务完全不可用的情况，直接在宿主机执行：

  docker stop <RabbitMQ容器名称>
  

  恢复的话用docker start重启容器。不过这个场景和单纯的网络故障略有不同，适合测试应用对服务完全下线的处理逻辑。

内容的提问来源于stack exchange，提问作者Kirill