I am working on an open source project, Homelab Proxy Manager. The goal is to create an easy interface that allows you to create reverse proxies easily to connect different containers to different domains in one easy package.
Because of this I need to allow my Nginx container to forward traffic to any other container the user is running. I don’t think docker networks are a good solution for this as that would allow all of the other containers to also communicate with each other.
Currently my solution that works is to use Host networking mode, which allows each docker container to be accessed by nginx by looking up the containers IP address. This is fine, but it would be nice to not use host networking mode so that my “Proxy Manager Service” isn’t exposed on some arbitrary port, and for it to also to allow port mapping in the case a user may want that. I was wondering if there was a any ideas for me to look into for this.
That would be an advanced network traffic management which is not available even in systems like Kubernetes by default. Kubernetes on the other hand supports network plugins like Calico which supports network policies like that.
There were some plugins for Docker as well, but it seems those were abandoned
I giess the developers focus on Kubernetes. If you don’t find a recent network plugin, you can try manually adding iptables rules, but none of those are really good ways for an open source proxy manager.
One thing that comes to my mind would require probably too many docker networks.
“proxy” as an external docker network to which the proxy manager connects.
A “proxy-connector” container in each compose project that needs the proxy manager to make it available.
“proxy-connector” network that is used for connecting from the proxy connector container and the server container.
The proxy manager would forward the request to the proxyconnectors, but would not be able to access the final server container. The proxy connector would be able to access the proxy and the server container. The server container would be able to access the proxy connector.
you would need to create small docker networks using small netmasks so they would not use too many ip addresses.
This was just a quick idea. I didn’t think it through yet.
What if I told you, that every container that publishes ports without binding them to a specific ip, always also binds to 172.17.0.1, which is the ip of the gateway for the docker default network. So in reality an arbitrary container could already probe for published host ports of containers on that ip.
I see following solutions:
each target container is also attached to the network of your reverse proxy.
This allows the reverse proxy and each target container to communicate with each other.
the reverse proxy is attached to each user defined network of the target containers.
This allows the reverse proxy to reach each target container, but does not allow containers of different networks to talk to each.
the verse proxy access the targets using the published port on ip 172.17.0.1.
Every target must publish a port (which could be limited to 172.17.0.1), but there is no benefit compared to the first solution as each container would be able to reach each other container on the published port. The same is true for your current host approach.
While the first and second approach do not require the target containers to publish ports, their expose is restricted to containers sharing the same container networks, the third approach allows every other container and process on the host to communicate with target containers using the published port.
Update2: my 2nd approach was wrong/incomplete: it indeed requires an extra network, as @rimelek wrote, for each target container for the isolation. Otherwise the reverse proxy would be able to communicate with all other containers in that network as well.
Thank you very much for those links, that was an insightful read!
That is an interesting solution, I think the complexity would outweigh the benefits in comparison to using network host mode in this case unfortunately.
I will look into that port publishing option, it seems intriguing. Potentially as a fallback option if host networking is a hard stop for some users as it still seems unfortunately limited (having to publish ports on your other containers). Thank you for the ideas
