Docker container as Proxy for docker daemon

I have a compose setup where a docker container acts as a proxy for the docker daemon to download images from a private registry.

That works but I need to figure out the container IP, set that value in the proxy settings, restart the docker daemon and hope that compose does not decide to change the IP of the proxy container. I figured out a specific way to achieve this but this feels really hacky. Additionally giving the proxy container a predefined static ip is also not an option as I need link networking within the compose setup.

Is there a way for the docker daemon to know the IP of a specific container dynamically? Like container can use their name as a domain but the daemon seems to use the host DNS resolver and therefore does not see the docker network DNS entries.

Thanks for any suggestions.

Use ipv4_address to assign a static ip to the container ip:

Though, it still feels hacky to run the proxy for docker inside a container.

Ah sorry I forgot to mention that a static IP with a predefined network won’t work as I need to use link networking within the compose file.

I am not sure what “link networking within the compose file” means.

Not even within a second attached bridge network? Well, then I am out of ideas.
I must admit, personally I would stay away from docker dependencies that are running inside a docker container on the very same docker engine.

As far as I am aware when you use

 - <container_name>

then you can’t set network settings like a specific network to use. And I don’t want to remove isolation between the containers or create multiple networks to achieve what I already have.

Concerning the proxy inside the container I thought about installing that on the host but it strikes me as the more “elegant” solution to have that as a container as this setup is more portable.

Why would you use link?

This is an ancient relic and is only useful for containers connected to the default docker bridge network.

Every docker compose network creates a user defined network that supports dns-based service discovery… just use the other service’s name to communicate with it.

I am confused as why this should prevent a container that uses link should have any effect on the network configuration. It simply injects the other containers name and alias into /etc/host of that container.

The only situation where ipv4_container makes no sense is if network_mode: is used, see:

I misremembered that I tried to use network_mode host for a different problem and encountered the incompatibility with linking container. Still new to most of this.

So if I understand you correctly then you would suggest using a defined network for all compose containers and then I am also able to set a static IP for the proxy container.

That should work :slight_smile: Thank you very much!

Yep. You might want to make it a habit to look up the compose file elements in the specification. Usually there are examples that show the usage, and a more or less brief description of what each setting does.

Just don’t follow tutorials you find on the internet blindly. In case of doubt, always look up the configuration elements in the compose file specification. Worst case you learn something new, or confirm that you already know.

1 Like