Docker containers aren't connected to host seemingly randomly

Docker Engine General
1

Hello!
I have a couple of containers on my personal server, but I’ve got an issue that I haven’t been able to pin down for a couple month now.

Whenever I restart my containers, they sometimes have no connection to host and therefore to the internet. I used to restart it a couple time and they just start working, but I think it’s time to fix it. All of my containers are on a common bridge, set like thin in compose:

networks:
  default:
    name: my_bridge_name
    external: true

I can see all of my containers connected to this network with this:

> docker network inspect my_bridge_name

What is weird thought, is that when I run nmcli, there is my bridge:

br-43599ecdbfc7: connected (externally) to br-43599ecdbfc7
        "br-43599ecdbfc7"
        bridge, 02:42:5E:C7:6E:B3, sw, mtu 1500
        inet4 172.18.0.1/16
        route4 172.18.0.0/16 metric 0
        inet6 fe80::42:5eff:fec7:6eb3/64
        route6 fe80::/64 metric 256

And many containers like so:

veth240ec6c: unmanaged
        "veth240ec6c"
        ethernet (veth), 06:EB:2F:7A:4C:E7, sw, mtu 1500

However, when I run ip address, there is my bridge, some of the containers have master field set, when others don’t (note for 54 there is a “master br-43599ecdbfc7”, which is the my docker bridge network I’m assuming):

52: veth7c316e3@if51: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 72:96:e3:f4:00:d1 brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet6 fe80::7096:e3ff:fef4:d1/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
54: vethb187b98@if53: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-43599ecdbfc7 state UP group default 
    link/ether 66:de:1a:65:64:1a brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::64de:1aff:fe65:641a/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

I can then edit it with this:

> sudo ip link set veth7c316e3 master br-43599ecdbfc7

And then the container is accessible from host.

What else can I look into, so that I don’t have to go through manually setting it so often?

2

I would make it explicit and give the bridge a real name and not use default, assign the network to all services/containers. Maybe that helps.

3

Hello, thanks for reply! As I said:

All of my containers are on a common bridge, set like thin in compose:

networks:
  default:
    name: my_bridge_name
   external: true

So it’s not a predefined “default” bridge - it’s my separate bridge, that I just have every container connected to. I believe, I did it this way when I started having this issue and this solution was one of the suggestions. Didn’t fix but didn’t hurt either.

4

The name default is just the handle in this compose project. Since you configured it as external and reference it by name, it isn’t any different from creating an additional network configuration.

If the compose project only needs a single network, I prefer it this way as well, as it prevents compose from unnecessarily creating a {project name}_default network.

Though, I can’t really tell you what causes your problem. I never experienced it.