For what exactly? I thought that was for slave<->master communication? There is no problem there. Or are you suggesting that from inside the running container I set at least LIBPROCESS_IP to the host IP rather than the IP of eth0 the container sees? Won't that screw with the docker bridge routing?
This doesn't quite make sense. I have other network connections inside this container and those channels are established and communicating fine. It's just with the mesos master for some reason. Just to be clear; * The running process is a scheduling framework * It does not listen for any inbound connection requests * It, of course, does attempt an outbound connection to the zookeeper to get the MM (this works) * It then attempts to establish a connection with the MM (this also works) * When the MM sends a response, it fails - it effectively tries to send the response back to the private/internal docker IP where my scheduler is running. * This problem disappears when run with --net=host TCPDump never shows any inbound traffic; IP 172.17.1.197.55182 > 172.20.121.193.5050 ... Therefore there is never any ACK# that corresponds with the SEQ# and these are just re-transmissions. I think! Jim On 10 June 2015 at 18:16, Steven Schlansker <sschlans...@opentable.com> wrote: > On Jun 10, 2015, at 10:10 AM, James Vanns <jvanns....@gmail.com> wrote: > > > Hi. When attempting to run my scheduler inside a docker container in > --net=bridge mode it never receives acknowledgement or a reply to that > request. However, it works fine in --net=host mode. It does not listen on > any port as a service so does not expose any. > > > > The scheduler receives the mesos master (leader) from zookeeper fine but > fails to register the framework with that master. It just loops trying to > do so - the master sees the registration but deactivates it immediately as > apparently it disconnects. It doesn't disconnect but is obviously > unreachable. I see the reason for this in the sendto() and the master log > file -- because the internal docker bridge IP is included in the POST and > perhaps that is how the master is trying to talk back > > to the requesting framework?? > > > > Inside the container is this; > > tcp 0 0 0.0.0.0:44431 0.0.0.0:* > LISTEN 1/scheduler > > > > This is not my code! I'm at a loss where to go from here. Anyone got any > further suggestions > > to fix this? > > You may need to try setting LIBPROCESS_IP and LIBPROCESS_PORT to hide the > fact that you are on a virtual Docker interface. > > > -- -- Senior Code Pig Industrial Light & Magic
