前言

之前我的一个小伙伴神父 - 嬷嬷在我们的公众号里发了一篇关于 docker 网络介绍的文章让人受益匪浅。期待他继续发表关于 docker 跨主机通讯方案的文章。今天我在这里就用工作中实际的例子来阐述针这几种网络模式的使用。

none 模式

docker 的网络模式中 none 是最特殊的了，它是告诉容器不使用任何网络。说白了就是连个 IP 都没有。这种看似没什么用的东西 (因为大家的测试环境肯定是要求有网络的) 按理说好像是没什么用才对。但我们确很非常多的使用这种模式，为什么呢？因为我们需要固定 IP。如果使用 docker 默认的 bridge 模式的话，容器的 IP 地址是会变得。这对测试来说不是一件什么好事。所以我们用 none 模式启动容器，然后使用 pipework 这个工具分配静态 IP 地址。下面是使用方式。

简单说明一下就是 pipework 会先检查是否有 br0 这个网桥，如果没有就创建一个新的。这样同一个网桥内的容器可以互相通信。后面跟着容器名称，容器 ip 地址和网关就可以了。这样我就有了一个不变的静态 ip 地址供我们在自动化中使用了。 pipework 的缺点是如果容器重新启动，ip 地址会消失。你需要重新指定。

container 模式

是在一个容器的网络设备挂在在另外一个容器下面作为桥介，连接到 docker0 网桥（我们这里假设使用默认的 docker0 网桥），从而实现网络通信，其实这种网络实现原理跟 host 很类似，在 host 模式下，容器是与主机 host 共享 namespace。这是我现在最常用的模式，在我目前的项目中都是 none+container 模式来部署各种环境和服务。启动第一个容器的时候使用 none+pipework 的方式分配静态 IP，之后所有的容器都使用 container 模式桥接到第一个容器的网络环境上。这样做的好处是所有容器公用一个网络环境，简单点说就是所有容器都是一个 IP 地址，对某个容器来说与其他容器通讯十分简单，因为对它来说所有容器的 IP 地址都是 localhost。外部感受不到任何区别，通过访问同一个 IP 的不同端口号来区分这些服务。有了这样的一个机制，我们的配置管理方案就简单明了了。如下：

最近微服务大行其道的背景下，单容器单服务越来越流行。一套环境由多个容器组成是很常见的。这对配置管理是一个挑战。如果不使用 container 模式让所有容器的 IP 地址相同。那么势必每个版本的配置都有多套方案。例如环境 A 一个配置文件，环境 2 又一个配置文件。。环境 N 有第 N 个配置文件。使用了 container 模式以后单一版本大家都用同一个配置文件就可以了，因为反正都是 localhost 么。 多的不说了，直接上使用方式

使用方式很简单，启动容器的时候再 net 里以 container:${容器名称} 就好了。这样就把网络挂载到容器上了。

host 模式

这个大家应该比较熟悉，跟 container 模式很像，可以简单的理解为把网络环境挂载到承载 docker 服务的主机上。通过暴露端口号的方式让人能以使用宿主机的 ip 来访问容器服务。这个不多说了。我不太喜欢这种方式。

bridge 模式

docker 默认的模式，也是我基本不用的模式。我现在所有环境都单机跑着呢，没啥跨主机通信的事情要做。所以研究也不深。就不丢人现眼了哈。就简单介绍下原理：Docker 安装好的时候会默认自动的创建一个虚拟的网桥被命名为 “docker0”，对于物理机来说 Docker0 相对于一块虚拟网卡设备。从容器角度来看，每运行一个容器，在启动以后就会自动生成虚拟网卡，连接到 docker0 上，确保启动的容器都能连接到 docker0 的容器，获取私有 IP 地址，组成一个私有的局域网。为了防止局域网内的 APR 冲突，Docker 进程在启动的时候也会分配一个随机的 MAC 地址。因此对于 Docker 容器来说，Dcoker0 却是一个虚拟交换机（三层交换机），这个 docker0 三层交换机不仅仅具有广播和转发二层数据包的功能，还兼容了路由功能进行三层的路由转发，所以除了 overlay 方式，它也是 docker 跨主机通信的方案之一，如果容器要是访问 192.169.1.x 网段的时候需要 eth0 转发，如果要访问 172.17.x.x 网段的时候，就要通过 docker0 进行转发，但是如果 docker 容器要访问外资源的时候，一般应该是经过 docker 转发到 eth0 物理设备，进而再次转到上层网络。具体转发原理，各位可以查看 linux iptable 具体的转发规则

总结

额，没啥好总结的，我就是个二手的 docker 使用者。希望有专业的运维同学指导一下我。