这个问题可能是针对所有docker大师的。但让我先介绍一下背景。我面临着dns解析问题(在docker的默认网络"桥"上)，直到我在https://docs.docker.com/engine/userguide/networking/
上面的docker network inspect命令显示了给定网络上所有连接的容器及其网络资源。此默认网络中的容器能够使用IP地址相互通信Docker不支持在默认网桥网络上自动发现服务如果您想与此默认网桥网络中的容器名称通信，则必须通过传统的docker-run-link选项连接容器。
由于--link选项被弃用，使任何docker run命令挂起，并最终破坏docker守护进程(本地)，我尝试使用不同的桥接用户网络并将虚拟实例固定到该网络。
docker network create -d bridge --subnet=172.15.0.0/16
--gateway=172.15.0.1
-o com.docker.network.bridge.default_bridge=false
-o com.docker.network.bridge.enable_icc=true
-o com.docker.network.bridge.enable_ip_masquerade=true
-o com.docker.network.driver.mtu=1500
-o com.docker.network.bridge.name=docker1
-o com.docker.network.bridge.host_binding_ipv4=0.0.0.0 a
docker run --name db1 -e MYSQL_ROOT_PASSWORD=a -d mysql:5.7.16
docker run --name db2 -e MYSQL_ROOT_PASSWORD=a -d mysql:5.7.16
docker network connect --ip 172.15.0.40 a db1
docker network connect --ip 172.15.0.40 a db2
现在，使用ping可以很好地解析通过--name命名的服务/容器，但问题是：
为什么在默认网桥网络上无法解析服务/容器名称
如果任何一个docker网络大师都能给出一个提示，那就太好了。当做
为什么在默认网桥网络上无法解析服务/容器名称？
没有技术原因不可能做到这一点，而是决定保持向后兼容性。
默认("网桥")网络从未支持通过内置DNS进行服务发现，当该功能正在开发时，一些项目的维护人员担心他们不希望将其添加到默认网络上，因为这会阻止其他实现。
此外，自定义网络被设计为显式允许容器进行通信。在默认网络上，这是通过禁用"容器间通信"(--icc=false)并使用--link在容器之间建立链接来实现的。对连接到默认网络的任何容器进行自动发现会使其使用起来更加复杂。
所以；创建一个自定义网络，如果容器应该能够相互通信，则将容器连接到该网络。
请注意，在许多情况下，并不是所有指定的选项都是必需的；简单地运行docker network create foo应该适用于大多数用例。