Docker Community Forums

Share and learn in the Docker community.

Way to connect to host's external interface from container in user network

Please help perhaps I am missing something trivial here.
I have two containers running
A) running in the user network
B) running on the host network (-network host) and listening external interfaces on the server

I see no way how to connect from A to B with the following constraints:

  1. I can’t put container A into host and user-defined network together to setup link
  2. can’t change network setup

Container A has no idea where it wants to connect to (it uses DNS name which resolves to the same-host external IP). The problem doesn’t exist for two different hosts.

Any ideas?

All Docker installations represent the docker0 network with bridge; Docker connects to bridge by default. Run ifconfig on the Linux host to view the bridge network.

When you run the following command in your console, Docker returns a JSON object describing the bridge network (including information regarding which containers run on the network, the options set, and listing the subnet and gateway).

docker network inspect bridge
Docker automatically creates a subnet and gateway for the bridge network, and docker run automatically adds containers to it. If you have containers running on your network, docker network inspect displays networking information for your containers.

Any containers on the same network may communicate with one another via IP addresses. Docker does not support automatic service discovery on bridge. You must connect containers with the --link option in your docker run command.

The Docker bridge supports port mappings and docker run --link allowing communications between containers on the docker0 network. However, these error-prone techniques require unnecessary complexity. Just because you can use them, does not mean you should. It’s better to define your own networks instead.

As already being expressed in the question, the DNS name got resolved via DNS service (like www.yahoo.com, not internal DNS), which gets resolved to an external IP.
Using links is not possible since there should be no link between containers, Container A should act as a external client for the server.

(think) though, arent the dns entries per network? So if Container A is in a custom network, but Container B is not, how is it supposed to to leverage the network’s dns for a network device not beeing present in the network?

Container A can address the docker host’s hostname/ip and Container B’s port to access the service in Container B. Container B could use localhost:{published port of Container A} to access services in Container A.

What prevents you to use a bridged network for Container B?
The long syntax to publish ports even allows to directly bind a host port (though, not sure if this is only available for overlay networks), instead of binding a host port to a container port

No, DNS entries are not per network, we are talking about the global DNS (not container managed dns).

Container B should be accessible not only from container A, but also from other sources.
Also as a requirement: B should be bound to host network (since it needs an access to a physical interface to bind to, that’s a requirement).

We can simplify the description and assume that there is no container B, just a service running on the host itself (without docker) and listening only external interface (not docker0).
If you want to run container on the same host, there is no way to connect to that service, but for the rest of the world - there is a very straight and simple. Looks like a logical issue to me.

If the context is container to container communication, why would you even consider that I would refer to anything else than a docker network managed dns?!

Honestly: I still have no idea what your problem is.
Your requirment and simplicity approach doesn’t help either, as a container running in --network=host runs in the network namespace of the host and has therefor network-wise identifcal behavior like any native process on the host.

I don’t get the point you try to make, please rephrase.