Re: [jgroups-users] How to find a valid bind address in docker

On 10/11/16 06:35, Questions/problems related to using JGroups wrote:

>     While WildFly can bind to the wildcard address, JGroups can't. It
>     requires the IP address of a valid local network interface. Why don't
>     you set system property -Djboss.bind.address.private=BIND_ADDR?
>
>     You could use symbolic names for BIND_ADDR, e.g.
>     match-address=192.168.1.\* or match-interface=eth2. Consult the manual
>     for more options.
>
>
> With bind address from `hostname -i`, peers find each other in
> standalone docker. See
> https://github.com/jboss-dockerfiles/keycloak/pull/59.
>
> With <interface name="private"><nic name="eth0"/></interface> which I
> guess corresponds to match-interface, wildfly starts (unlike with
> 0.0.0.0) and detects the same IP as `hostname -i`, for example "local
> address is keycloak-2682131713-lh4q2, physical addresses are
> [10.0.3.185:55200 <http://10.0.3.185:55200>]".

Good!

IIRC,Wildfly also has some matching capabilities, e.g. 192.168.0.0/16. 
I'm not sure if they actually allow for syntax like match-interface, 
which is JGroups specific. I think they have their own syntax and then 
inject the bind address into JGroups...


> Wildcard will probably make no difference, as /sys/class/net only lists
> eth0 and lo and `hostname -I` only lists the IP above. I guess the same
> goes for <any-address/>
> (https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)

OK

> Peers still don't find each other however. How do I check, from a peer,
> that bind works?

Hmm... You could use probe.sh, ie. java -Djava.net.preferIPv4Stack=true 
-cp jgroups.jar org.jgroups.tests.Probe jmx=TCP.bind jmx=TCPPING (if you 
use UDP, then jmx=UDP.bind).

This requires diagnostics to be enabled, check the Wildfly manual for 
how to do this in the transport (TCP or UDP).

> I guess it does because if I switch to tcp I can even
> curl the other instance on http://10.0.3.186:7600 (new container so new
> IP) and get "Empty reply from server" instead of "Connection refused".

OK, then TCP.bind_addr seems to be correct. Then you need to see if 
TCPPING works. Use probe.sh above to see if TCPPING.initial_hosts is set 
correctly to list all bind_addrs/ports.

>     > Background: I'm trying to run Keycloak 2.3.0 in Kubernetes. Each
>     > instance will have its own Service, and the service gets an IP address
>     > that is not the same as that returned by `hostname -i`.
>
>     Can't you use KUBE_PING for discovery protocol, instead of TCPPING? It
>     was written specifically for Kubernetes. TCPPING will work, too, but
>     there's more configuration work to be done to make it work.
>
>
> KUBE_PING makes undocumented assumptions about cluster internals such as
> access to the API. It seems based on OpenShift. The environment
> variables it needs are not available in google container engine. Also
> its design principle with using labels is significantly more complex
> than TCPPING.

OK. Did you look at the instance in jgroups-extras? AIUI KUBE_PING has 
been cleaned up and deps have been removed.

> I suspect that multicast isn't supported. I see the following options now:
>  - As I wrote in the original post, peers can construct the TCPPING
> initial_hosts string based on env vars.
>  - Use JDBC_PING, or if that fails use GOOGLE_PING.

If you run in a GCE env, then I'd prefer GOOGLE_PING. I used it to start 
a 2000+ node cluster, some scripts are in https://github.com/belaban/google.

> What do you think?
>
> /Staffan
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
>
>
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi