WSL2下Docker容器未自动加入桥接网络致通信失败的非compose解决方案问询

你踩的是Docker网络设计里最容易搞混的经典坑，和WSL2环境本身的适配偏差叠加后就出现了你现在遇到的现象：

• Docker内置的、名称为bridge的默认桥网络，从设计之初就不提供内嵌的容器DNS解析能力。哪怕所有容器都正常挂载到这个网络上，也只能通过分配到的IP互相访问，完全没法靠容器名通信
• 你之前看到的“入桥即可通过名称互通”的官方说明，描述的是用户手动创建的自定义桥接网络的能力——这类网络默认开启内嵌DNS、同网容器全互通、隔离性更好，和内置的默认bridge完全是两套实现
• WSL2环境下的Docker Desktop还有个额外的偏差：因为要适配WSL2的虚拟网络层，它根本不会把动态创建的容器自动绑定到内置的bridge网络上，等于从根上就断开了默认网络的连接，自然连基于IP直连的默认网络能力都用不上

所有方案都适配你动态创建容器跑集成测试的场景，不需要改动现有测试流程：

• 方案1：修改守护进程默认网络绑定，一次配置永久生效
  1. 提前创建一次长期使用的共享桥网络，执行docker network create app_shared_net即可，这个网络创建后会永久留存，不需要每次重建
  2. 打开Docker Desktop的设置面板，进入Docker Engine配置页，在现有JSON配置里追加参数，把新建容器的默认绑定网络从内置bridge改成你刚创建的共享网络：

     {
       "bridge": "",
       "default-network": "app_shared_net"
     }
     

  3. 保存配置重启Docker生效后，不管是手动启动的容器，还是集成测试脚本动态拉起的容器，都会自动加入这个共享网络，完全不需要每次启动都手动指定--network参数，网络自带的DNS服务会自动生效，直接通过容器名就能互相通信
• 方案2：用网络别名实现默认桥下的名称互通
  如果不想改动全局守护进程配置，可以在动态创建容器的流程里，给每个待通信的容器添加--network-alias <自定义通信标识>参数。哪怕容器挂在内置的默认bridge上，同网的其他容器也能通过这个指定的别名访问，不需要额外挂载自定义网络
• 方案3：在现有创建脚本里加一行自动入网逻辑
  因为你的集成测试是通过固定脚本入口动态创建容器的，只需要在容器启动完成的命令后面，追加一行自动连接共享网络的逻辑，比如执行docker network connect app_shared_net $CONTAINER_ID。这行逻辑只需要在脚本里加一次，后续所有动态创建的容器都会自动加入目标网络，不需要手动逐个操作

• 内置默认bridge的设计初衷是兼容Docker 1.9版本之前的老旧流程，官方本身就不推荐在正式场景使用，把默认网络切换到自定义桥网络本身就是标准最佳实践
• 你当前使用的Docker Desktop 3.2.2是2021年的老版本，WSL2网络适配存在已知的绑定bug，如果修改配置后依然出现容器网络挂载失败的问题，可以临时关闭再重新打开WSL2集成开关重启一次，不需要升级版本也能正常运行

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