Share and learn in the Docker community.
Hi, everything is in the title.
I would like to reach from my container devbox, another container to link stuff etc . anyway I can’t seem to reach the container with the ip address of my host server docker and so it seems that I need to have the ip from the container itself. Is there a way to activate the loop or something?
by the way it’s on linux. (the host server docker i mean)
You’re supposed to be able to. You’ve started your container with the docker run -p option so the port is published on the host? You don’t have a restrictive host iptables firewall configuration that’s blocking it?
You should never need this for most situations I know of. It’s also not (by default) routable or especially unique: my system and yours both probably have 172.17.0.0/16 Docker private networks, and if my host tried to get to 172.17.0.2 the packets would never leave my box.
You’re supposed to be able to. You’ve started your container with the docker run -p option so the port is published on the host? You don’t have a restrictive host iptables firewall configuration that’s blocking it?
yes I run it like that. this container is more like a testbox. A box where I can go toany website I want without risking to contaminate other things for example because of malicious code. No personal data stored or anything else. the iptables is of course restricted but when you create a container by publishing the port, it opens autmatically the port on the forward table from docker so that’s not supposed to be a problem. Plus I can reach the 2 container outside.
You should never need this for most situations I know of. It’s also not (by default) routable or especially unique: my system and yours both probably have 172.17.0.0/16 Docker private networks, and if my host tried to get to 172.17.0.2 the packets would never leave my box.
that was I thought but it doesn’t seem to work and I’m a bit clueless on that one. Maybe could you try? the concerned container is 
warehouseman/xubuntu-x2go-phusion "/sbin/my_init" 3 days ago Up 22 hours 0.0.0.0:45117->22/tcp test
@boistordu, do you want this to be available from another container or from the host?
if it’s from the host, run -p hostport:containerport should work fine to route containerport to 0.0.0.0 (localhost included here)
if it’s from container to container, put them on the same docker network
$ docker network create mynet
$ docker run --name foo --net mynet img
$ docker run --name bar --net mynet img
You will be able to reach foo and bar from each other using DNS entries corresponding to the container name, e.g. curl foo should work from bar if you’re serving something on port 80/443 in foo
From the host it has never been a problem .
It’s from a container. Is your solution the same thing basically than link? I wanted to avoid to change run parameters and so I was asking myself and you then, why can’t I do some sort of a loop?
Since the host server is some sort of a DNS server for the docker NAT, it seems strange to me that a packet can’t do: APP in container A —> interface container A -----> interface SERVER DOCKER -----> loop ----> interface SERVER DOCKER ----> interface container B -----> APP of container B …
Or maybe is it like in the ubiquiti router or others that the local loop is not activated and we should put a static route in our iptables or something for that?
Thanks anyway for the answer even if it’s a bypass to my question
It’s better than --link – --link is deprecated. Docker networks allow for bidirectional communication and don’t require cascading restarts if you need to restart one container on the network.
Why? That’s why they’re present, to modify container runtime behavior.
I’m not sure if I understand what you’re going for here, but you seem to be describing very similar to what having two containers on the same bridge network (as outlined above) does do. The two containers will be connected to the same docker0 bridge on the host and each will have an IP on that bridge. Because Docker daemon is used for top level DNS server, in containers, a DNS entry for container 1’s name will resolve to the bridge IP of that container in container 2.
got it for the link option which is deprecated.
well run parameters means that we have to rm and restart the containers that why I wanted to avoid it. It would be so cool that we could change this thing on the move.
I will try to be more clearer for the next part but i need a bit more time to explain myself.
it seems also that we can use only one network at a time right?
So basically you want your container to find another containers ip address?
You could create 3 containers: your 2 containers that need to discover each other and one container that will have a volume that you share with the other 2 containers.
When you boot your container that needs to be discoverable, you write its ipaddress and optionally a identifier to a file in the shared volume. Your other containers can detect writes to that volume, read the file and grab the new containers ip address.
This is how I would solve this problem.
No, if you just want two containers to be able to communicate with each other using the network, this is a way over-complicated solution. Please don’t do this.
it seems also that we can use only one network at a time right?
No, a container can be connected to multiple networks. You just have to use docker network connect in addition to (or in lieu of) docker run --net.
e.g.
$ docker network create foo
69f42dc1d56389b5192eaecbc98b70890476583ada30d767842e3e7879a3f5c7
$ docker network create bar
74531c1629b05988dd662bb090f9fbb81137ea38141fa17d7bdf71d130d49298
$ docker run -d alpine sleep 3000
964cbb8b02318d4fab807d1b73d2ed04e98519da6623143b6c047a04dcba0926
$ docker network connect foo 964
$ docker network connect bar 964
$ docker inspect -f '{{ range $name, $element := .NetworkSettings.Networks }}{{ $name }} {{ end }}' 964
bar bridge foo
@nathanleclaire totally forgotten to thank you:) very useful this docker network connect 