My recommendation is to never use explicit IP addresses anywhere inside Docker space. Don’t use a --subnet option here, and don’t use a --ip option when starting your container. But:
If you add an explicit --name option to this, whatever name you provide here will be visible as a DNS name to other containers on the same network; and since you specified -p 9400:9400, from outside Docker space, you can also access this service via port 9400 on the host.
I’ll note that the two commands you gave have the same -p 9400:... host port, so one of them will fail to start up. Or, if when you say “node” you mean you have three physically separate hosts, unless you’ve done something special, each node has its own Docker daemon and its own private networking space, so you actually have three separate “mynet” networks, one on each host; you’d need an overlay network if you want them to communicate.
Well the static IP is temporary until we get our kubernetes/skydns setup in place but the application we are running has to know the IP addresses of all the other nodes at application startup so using static IP’s for the time being.
the problem is that the ‘network’ doesn’t know about each other… and are not homogeneous.
so, when u ping from container A on host A to container B on host B, the address MUST be inside the network you defined on host A. there is nothing to tell the gateway otherwise.
docker networks are pretty useless across systems.
on top of that, because the ip addresses are on a private network, under the host, there is no mechanism to route from container on host A to a container on Host B.
you could use one of the overlay networks, like Weave. you have to assign addresses there too.
but the containers still cannot be connected to from outside the weave network on the weave assigned IP addresses… only thru port mapping to the host ip address