docker-compose 创建容器引起的局域网访问问题

事因

因为用 docker-compose 相对方便后期维护，而且创建容器时可以有个记录根据，所以创建容器便一直用 docker-compose 进行创建。

问题的起因也很简单，有人回馈服务器的服务无法访问了，然后上去一顿猛如虎，很明显，没问题，后来一段排查后，发现回馈问题的机器所处网段与服务器一个叫 br-xxxxx 的网桥网段一毛一样，经过测试，嗯，实锤了。

局域网中一台 172.18.0.x 的机器访问服务器，此时服务器中因为使用 docker-compose 创建容器，默认情况下会去创建一个叫 compose_default 的网桥，而其网段就是 172.18.0.0/16，局域网这台机器访问（ 或者 ping ）服务器后，服务器不会回复这台机器，导致 GG。

测试

  • 删除测试服务器中的容器（ 这里我是有 compose 文件，其他创建好后需要配置的东西也有记录，而且是测试环境，正常情况没事别在生产机上乱操作，莫成为删库跑路的下一人 ）

嗯，删除后发现可以 ping 通了

  • 通过 docker-compose 创建一个自定义网桥，再将容器创建的 compose 文件增加一个 networks 指向
1
2
3
4
5
6
7
version: '2'
networks:
  t-network:
    ipam:
      config:
       - subnet: 169.19.0.0/16
         gateway: 169.19.0.1
1
2
3
4
5
6
7
8
9
10
11
12
13
version: '2'
services:
  nginx:
    image: nginx
    container_name: nginx
    ports:
     - 80:80
     - 443:443
    networks:
     - t-network
    volumes:
     - /etc/localtime:/etc/localtime
     - /etc/timezone:/etc/timezone
  • emmmm… 可以访问了。

结言

嗯，不生产这个同网段的即可。（ 简直废话 ）

附加

后来看到直接使用 docker run ..... 的方式创建的容器，使用的是默认的 docker0 ，嗯，折腾一下。

把上面的

1
2
3
4
5
services:
  nginx:
    ...
    networks:
     - t-network

改成

1
2
3
4
5
services:
  nginx:
    ...
    network-mode: bridge
     - t-network

即可。

差异

使用 自定义网桥 和 docker0，有一个最明显的差异。

自定义网桥的话，可以直接通过 容器名 访问到，而通过 docker0 创建的不能通过 容器名 访问到（ 等同于 docker run 启动，需要用 –links 才能访问到 ）。