weixin_42445065的博客

在这种网络下，Docker 宿主机在它的IP之上，允许接受多个 MAC 地址的请求，然后再将这些请求路由至对应的容器里。流通，Docker 会用它的 MAC 地址，把流量路由进你的容器里。对于网络上的网络设备来说，你的容器似乎是物理上连接到网络上的。），Docker使用其MAC地址将流量路由到你的容器。对于网络上的网络设备来说，你的容器似乎是物理上连接到网络上的。你需要 3.9 或者更高版本的 Linux 内核，4.0 以及以上的版本是更好的。如果你的设备叫别的名字，用对应的名字代替。

演示了如何创建和使用你自己的自定义 overlay 网络，以连接服务。建议在生产环境中运行的服务使用这个方法。

网络驱动只适用于Linux主机，不支持Docker Desktop for Mac、Docker Desktop for Windows或Docker EE for Windows Server。本系列的教程涉及直接绑定在 Docker 宿主机网络上而不隔离网络的独立容器的联网问题。进程直接运行在 Docker 宿主机上而不是在容器中的隔离程度相同。这个过程要求Docker主机上的80端口是可用的。容器，直接绑定到 Docker 宿主机的80端口。检查所有的网络接口，确保没有新的接口被创建出来。

在这个例子中，我们再次启动了两个alpine容器，但不同的是，我们把它们连接到我们已经创建的一个叫做alpine-net网络的用户定义的网络。这些容器没有连接到默认的bridge网络。然后我们启动第三个alpine容器，它连接到bridge网络，但没有连接到alpine-net，第四个alpine容器则同时连接到两个网络。创建alpine-net网络。你不需要用标志来指定使用的是 bridge 驱动，因为 bridge 就是默认的方式。但例子里还是展示了如何指定它。Inspect 一下。

通过在容器内执行一些常见的网络命令来检查容器的协议栈。在容器内，只有回环设备被创建。下面的例子说明了这一点。如果你想完全禁用容器上的协议栈，你可以在启动容器时使用。第二个命令返回空，因为容器中没有路由表。标志，因此会被自动销毁。

网络驱动为每个容器的虚拟网络接口分配一个MAC地址，使其看起来像一个直接连接到物理网络的物理网络接口。在这种情况下，你需要在你的Docker主机上指定一个物理接口来用于。如果你的应用程序可以使用 bridge（在单个Docker主机上）或 overlay（在多个Docker主机上通信）来工作，从长远来看，这些解决方案可能更好。由于IP地址耗尽或 "VLAN扩散"（即在你的网络中拥有不适当的大量唯一MAC地址的情况），你的网络很容易在无意中被破坏。你甚至可以用不同的物理网络接口来隔离你的。

（讨论下来）一个要点是，操作者有能力将他们的物理网络映射到他们的虚拟网络中，以便将容器整合到他们的环境中，而不需要进行操作上的大改动。Linux 的实现是非常轻量级的，因为它们不是使用传统的 Linux 网桥进行隔离，而是与一个 Linux 接口或子接口相关联，以执行网络之间的分离和与物理网络的连接。网络路由器上的次选地址是很常见的，因为一个地址空间有可能有用完的情况，此时可以在三层的 VLAN接口上增加一个次选地址，或者通常称为 "交换机虚拟接口"（SVI）。该子网是隔离的，除非上游网络在VLAN。

在这种情况下，控制流量（与管理 swarm 和服务有关的流量）依然通过 overlay 网络传递，单独的 swarm 服务容器则使用 Docker daemon 的宿主机网络和端口发送数据。Host 模式网络在优化性能方面很有用，在容器需要处理大量端口的情况下也很有用，因为它不需要网络地址转换（NAT），而且不会为每个端口创建 "用户区代理（userland-proxy，关键字 docker-proxy）"。模式且绑定了80端口的容器，那么该容器的应用程序就可以在宿主机 IP 地址的80号端口上使用。

大多数用户从来不需要配置ingress网络，但 Docker 允许你这样做。如果自动选择的子网与你的网络上已经存在的子网相冲突，或者你需要定制其他的底层网络设置，如 MTU 大小，这时就会很有用。自定义ingress网络的过程包括移除并重新创建它。这通常是在你在 swarm 中创建任何服务之前完成的。如果你有一些服务已经公开过端口（用 -p 或者 --publish），那在你删除ingress网络之前，这些服务需要被先被删除。在没有ingress网络时，没有公开端口的服务继续运行，但无负载均衡。

用户定义的 bridge 提供容器之间的自动 DNS 解析。在默认 bridge 下的容器只能通过 IP 地址访问彼此，除非使用 --link 选项，此选项已经标记为遗弃状态。而在用户定义的 bridge 网络，容器间可以通过主机名或者别名来解析彼此的地址。想象有一个应用栈，包含了一个网页前端跟一个数据库后端。假设你分别命名两种容器为web和db，无论应用栈在哪个 Docker 宿主机跑着，web容器都能够连接db容器里面的数据库。

字段的配置对 Docker client 连接的所有的 daemons 都会生效。但是，配置只会对接下来新的容器跟构建起作用，已有的则不会受影响。当你调用构建时，代理相关的构建参数会根据 Docker client 配置文件中的代理设置自动预填充。把代理环境变量集成到镜像里也可能导致安全问题，因为这些代理环境配置里可能会包含一些敏感的信息。不幸的是，目前还没有一个标准来定义网络客户端应该如何处理代理环境变量，也没有定义它们的格式。Docker 的构建跟容器都会用到在这个配置文件里的信息。

使用之后，容器中会创建一条防火墙规则，将容器的端口跟 Docker 宿主机中的端口映射起来。容器能看到的，是一张配置好 IP 地址、网关、路由表、DNS 服务跟其他网络信息的网卡。同样的，容器的主机名默认是容器在 Docker 里的ID号。将一个已经存在的容器连接到一个不同的网络的时候，类似的也可以在指令里用。将一个已经存在的容器连接到一个不同的网络的时候，可以使用。一个容器并没有它连接的网络类型的信息。命令把一个运行中的容器连接到多个不同的网络。标志，给这个容器在对应的网络中起一个额外的网络别名。

Docker 容器和服务(Service) 很强大的原因之一，是你可以将它们互联，或者干脆将它们连接到Docker 之外的地方去。Docker 容器和服务甚至不需要知道它们是否被部署在 Docker 上，又或者需要知道它们的对端(peer)是不是 Docker 服务(workload)。无论你的 Docker 跑在Linux、Windows 又或者是它们的混合体之中，你都可以用 Docker 来对这些容器和服务进行平台无关的管理。