默认桥接网络上的docker嵌入式dns [英] docker's embedded dns on the default bridged network

问题描述

这个问题可能已经解决了所有码头工人。但是，让我先提供一些背景知识。我遇到了dns解析问题（在docker的默认网络网桥上），直到我在 https://docs.docker.com/engine/userguide/networking/

This question is probably addressed to all docker gurus. But let me give some background first. I faced dns resolution problems (on docker's default network "bridge") until i read the following in the documentation at https://docs.docker.com/engine/userguide/networking/

上面的docker network inspect命令显示给定网络上所有连接的容器及其网络资源。此默认网络中的容器能够使用IP地址相互通信。 Docker不支持默认网桥网络上的自动服务发现。如果要与此默认网桥网络中的容器名称进行通信，则必须通过旧版docker run --link选项连接容器。 / p>

The docker network inspect command above shows all the connected containers and their network resources on a given network. Containers in this default network are able to communicate with each other using IP addresses. Docker does not support automatic service discovery on the default bridge network. If you want to communicate with container names in this default bridge network, you must connect the containers via the legacy docker run --link option.

不推荐使用-link 选项，使任何 docker run 命令挂起，最后（本地）粉碎了docker daemon进程，我尝试使用其他桥接用户网络并将虚拟实例固定到该网络。

As the --link option is deprecated, makes any docker run command hang and finally smashes the docker daemon process (locally) i tried using a different bridged user network and pinned dummy instances to it.

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

现在解析服务/容器通过-name 命名可以使用 ping 正常工作，但这是一个问题：

Now the resolution of services/containers named via --name works fine using ping but here is the question:

为什么在默认网桥网络上无法解析服务/容器名称？

如果有任何docker网络，那将是很好的选择上师可能会提示。问候。

Would be great if any docker network guru could give a hint. Regards.

推荐答案

为什么在默认网桥网络上无法解析服务/容器名称？ / p>

Why is service/container name resolution not possible on the default bridge network?

这是没有技术原因的，但这是保持向后兼容性的决定。

There's no technical reason this would not be possible, but a decision to keep backward compatibility.

默认（桥接）网络从不支持通过内置DNS进行服务发现，并且在开发此功能时，某些项目的维护者担心他们不希望在默认网络上添加此功能，因为

The default ("bridge") network never supported service discovery through a built in DNS, and when the feature was under development, maintainers of some projects raised concerns that they did not want this added on the default network, as it would block alternative implementations.

此外，自定义网络旨在明确地允许容器进行通信。在默认网络上，这是通过禁用容器间通信（-icc = false ）并使用-link 在容器之间建立链接。对连接到默认网络的任何容器进行自动发现会使使用起来更加复杂。

In addition, custom networks are designed to explicitly allow containers to communicate. On the default network, this is achieved by disabling "inter container communication" (--icc=false), and using --link to establish a link between containers. Having automatic discovery for any container connected to the default network would make this a lot more complicated to use.

创建自定义网络，并在容器之间能够相互通信的情况下将其附加到该网络。

So; create a custom network, and attach containers to that network if they should be able to communicate with each other.

请注意，在许多情况下，并非您指定的所有选项需要;只需运行 docker network create foo 即可在大多数情况下使用。

Note that in many cases, not all of the options you specified are needed; simply running docker network create foo should work for most use cases.

这篇关于默认桥接网络上的docker嵌入式dns的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！