> On June 11, 2015, 7:34 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/src/process.cpp, lines 820-836 > > <https://reviews.apache.org/r/34128/diff/2/?file=963212#file963212line820> > > > > If two libprocess based unix processes (e.g., scheudler and master) are > > within the *same* bridged container, would they able to communicate with > > this change? Can you test this to confirm? > > > > > > If not, a better option might be to instead have LIBPROCESS_BIND_IP and > > LIBPROCESS_BIND_PORT that just changes the address we bind to. > > LIBPROCESS_IP and LIBPROCESS_PORT semantics could be left untouched. > > Anindya Sinha wrote: > If 2 libprocess based unix processes are running, they would point to a > different <public_ip:public_port> (most likely same public_ip but a different > public_port, ie. same LIBPROCESS_PUBLIC_IP but a different > LIBPROCESS_PUBLIC_PORT). The processes themselves would bind as it does today > on <ip:port> (based in LIBPROCESS_IP and LIBPROCESS_PORT). Once a request > lands on a corresponding <public_ip:public_port>, a proxy listening on that > would forward that to the actual <ip:port> corresponding to the > <public_ip:public_port>. > > As an example, mesos-master binds on 10.11.12.13:5050 (ip:port) with > public_ip:public_port as 192.168.100.100:6050, and say scheduler binds on > 10.11.12.13:8081 with public_ip:public_port as 192.168.100.100:9081. Requests > received on 192.168.100.100:6050 shall be proxied over to 10.11.12.13:5050 > (to reach mesos-master) and requests received on 192.168.100.100:9081 shall > be proxied over to 10.11.12.13:8081 (to reach scheduler). > > Vinod Kone wrote: > ``` > a proxy listening on that would forward that... > ``` > > who sets up this proxy? or do you mean this is what happens currently in > bridged mode containers (e.g., docker)?
No this is not something that is part of docker. The proxy would be something external to the container which would proxy the request to your application within the container. This patch enables external entities viz. zookeeper reach the host (based on public_ip:public_port) from where a proxy will be required to route to the application running within the container. If we use <ip:port>, zookeeper won't be able to reach. The setting up of the proxy is not a part of docker or libprocess. Please also refer to relevant issue https://issues.apache.org/jira/browse/MESOS-2587. - Anindya ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34128/#review87611 ----------------------------------------------------------- On May 18, 2015, 10:08 p.m., Anindya Sinha wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34128/ > ----------------------------------------------------------- > > (Updated May 18, 2015, 10:08 p.m.) > > > Review request for mesos. > > > Bugs: MESOS-809 > https://issues.apache.org/jira/browse/MESOS-809 > > > Repository: mesos > > > Description > ------- > > Expose environment variables LIBPROCESS_PUBLIC_IP and LIBPROCESS_PUBLIC_PORT > as the IP and > port which libprocess would advertise (if set). If not set, it defaults to > the IP and port on which it binded to. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > e3de3cd6b536aaaf59784360aed546512dd04dc9 > > Diff: https://reviews.apache.org/r/34128/diff/ > > > Testing > ------- > > Testing: > make test > > > Thanks, > > Anindya Sinha > >
