@mwav3
Home Assistant only runs in “host” network mode if you add network_mode: host
to that service in your docker-compose, Home Assistant doesn’t have to run in host network mode. When running containerized services I prefer to expose only exactly what needs exposed.
According to the docker-compose docs (Networking in Compose | Docker Docs):
By default Compose sets up a single network for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.
So in this situation, caddy
is the container name and therefore the hostname; because I’m not running network_mode host, this should just work; and it does work for many other things like my mqtt setup.
The docs also say:
If you make a configuration change to a service and run docker-compose up
to update it, the old container is removed and the new one joins the network under a different IP address but the same name. Running containers can look up that name and connect to the new address, but the old address stops working.
So, if the IP changes and you’re referencing the hostname in Home Assistant’s configuration, then things should be fine.
For now I’ve grabbed the IP out of Home Assistant’s logs and hardcoded it here (I also verified that this IP is the IP of my caddy service):
http:
use_x_forwarded_for: true
trusted_proxies: [hardcoded IP here]
I was thinking the configuration should just be (however this doesn’t work, here is the conatiner/network name: tbro-server/home-automation/docker-compose.yml at 4725320f1224dc73032b0507fa944f4893821fca · TonyBrobston/tbro-server · GitHub):
http:
use_x_forwarded_for: true
trusted_proxies: caddy
But I’m wondering if it should really be http://caddy
or http://caddy:443
or something along those lines… it’s also possible that there is a bug and it doesn’t work by network name, though the docs say it should here: HTTP - Home Assistant
List of trusted proxies, consisting of IP addresses or networks, that are allowed to set the X-Forwarded-For
header.
It’s also possible to hardcoded the IP of the container in the docker-compose, however this shouldn’t be necessary based on the rest of the info above. I try my best not to subscribe to “just getting it to work”, less code = less maintenance; I try my best to let the abstractions do their job.
Does anyone else have any ideas? I’m certainly opening to trying some suggestions.