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

Thank you. I have two questions and some more background.

On Tue, Nov 8, 2016 at 3:48 PM, Questions/problems related to using JGroups
<[email protected]> wrote:

> Hi Staffan,
>
> On 08/11/16 14:06, Questions/problems related to using JGroups wrote:
> > HI,
> >
> > My attempts to accept TCPPING or any other connections from non-local
> > peers are blocked by org.jgroups.util.Util.checkIfValidAddress. See
> > stack trace below.
> >
> > My easiest way out would be to bind to 0.0.0.0 but register a logical IP
> > address as the external bind address. Can that be done?
>
>
> 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]".

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)

Peers still don't find each other however. How do I check, from a peer,
that bind works? 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".


> > 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.

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.

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