Docker image remove requirement for host networking

Feature Requests
1

Proposal:
Currently, the only supported way of running home assistant in docker is with host networking (“network_mode: host”, “-net=host”). Adopt “bridge” mode as as “supported configuration with caveats”. I understand not everything can work in bridge mode, that’s not my proposal.

  • Allow documentation PRs focused on running in “bridge” mode to be submitted.
  • Any integration that requires host mode be listed as such in the integration’s documentation.
  • If an integration goes from not requiring host networking, to requiring it, it’s treated as a breaking change and documented as such.

Reason for Proposal:
There are many reasons for wanting to use bridge mode: security (link) and interoperability with other service containers like nginx_proxy (link).

Recent changes to the google cast introduced in 0.109 (link) have made host networking mandatory. I’ve locked my version to 0.108 to avoid this host networking requirement. Running in host network mode isn’t an option for me, going without google cast support isn’t an option for me, leaving the version at 0.108 isn’t an option forever, so I’m not sure what my options are for staying with home assistant.

Documentation PRs have been submitted to help people who want to run the docker container in bridge mode, but the PRs have been rejected because they describe “a way of running HA that is not supported by the HA team”. (link)

Please leave post open:
The github tickets around this issue are getting closed, which prevents discussion. I’d hope this post can be left open for discussion.

2

Isn’t the mDNS )Google Cast) requirement just a matter of mapping -p 5353:5353/udp?

Are there other ports that are typically required (besides tcp 8123, of course)?

3

I think google cast is single use case. There is also Airplay, emulated hue and several other services.

Honestly its been a while since I try making mdns work with docker bridge but I do remember I never was successful with it so I believe it is slightly more complicated than forwarding needed ports but my networking is mediocre and I may be dead wrong. There is also so mdns reflector enable magic for some networks I believe.

4

I have tried mapping 5353/udp, but it didn’t seem to work. I don’t fully understanding multicast dns, but it seems to need more. I’ve since started using the image “monstrenyatko/mdns-repeater” to forward the mdns traffic from the host interface to the bridge interface, which has been working well for a while now.

I’m more disappointed that the official documentation actually forbids mention of “workarounds” like this. I consider support for running in bridge mode to be essential.

mdns-repeater:
    image: monstrenyatko/mdns-repeater
    container_name: mdns-repeater
    restart: unless-stopped
    command: mdns-repeater-app -f enp2s0 br-d1b70d5d1549
    network_mode: "host"
1 Like
5

It’s more than just ports, multicast is not the same as unicast. It’s a different type of address, it’s essentially a broadcast on home networks that all hosts see. OS’s support this by having a multicast agent/process that listens and routes the traffic to any process that register with it (because multiple processes may need to see the same message). Being a broadcast it can’t cross network boundaries into the container space.

Docker has no support for multicast routing, so network=host is the only option.

Sure you can register a different container but you have to be careful that it isn’t eating other multicast address traffic. So maybe it works for mDNS but now UPnP breaks, etc. Not all m/c services use unique multicast addresses.

3 Likes
6

It seems like it would be useful to isolate services that really need unrestricted host network access into separate, small containers.