You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Kristian Rosenvold <kr...@apache.org> on 2016/05/12 07:56:18 UTC

Tcp discovery with clustered docker nodes

We have been using jdbc based discovery successfully, but have been trying
to get this to work with docker. The problem is of course that all the
internal IP's inside the docker container are useless, so we'd really need
some way to override the discovery mechanism. Now you could of course say
that I should be using the static mechanism, but configuration-wise it
makes things really messy.

It would be much cleaner to simply make each node publish its "correct"
external address to the discovery api, so that the JDBC discovery mechanism
would contain only the external address (ignoring loopbacks here, unsure if
there is a use case).

By reading the source it would appear that this is not really supported, or
am I missing something ? (It would appear like I need some kind of
ovverride in the TcpDiscoveryMulticastIpFinder#initializeLocalAddresses/U.
resolveLocalAddresses
area).


Kristian

Re: Tcp discovery with clustered docker nodes

Posted by Alexei Scherbakov <al...@gmail.com>.
Please look at IgniteConfiguration.setAddressResolver.
It should do the job by mapping internal to external IP.

2016-05-12 16:26 GMT+03:00 Kristian Rosenvold <kr...@apache.org>:

> To ny understanding no; the java process running innside the docker
> container has no possibility of binding to the externally visible ip/port.
>
> Kristian
> 12. mai 2016 3.22 p.m. skrev "Alexei Scherbakov" <
> alexey.scherbakoff@gmail.com>:
>
>> Hi,
>>
>> TcpDiscoverySPI has two properties(localAddress and localPort), which
>> allows you to set local address and port for Discovery SPI to bind.
>> T
>> Does it solve your problem?
>>
>>
>> .
>>
>>
>> 2016-05-12 10:56 GMT+03:00 Kristian Rosenvold <kr...@apache.org>:
>>
>>> We have been using jdbc based discovery successfully, but have been
>>> trying to get this to work with docker. The problem is of course that all
>>> the internal IP's inside the docker container are useless, so we'd really
>>> need some way to override the discovery mechanism. Now you could of course
>>> say that I should be using the static mechanism, but configuration-wise it
>>> makes things really messy.
>>>
>>> It would be much cleaner to simply make each node publish its "correct"
>>> external address to the discovery api, so that the JDBC discovery mechanism
>>> would contain only the external address (ignoring loopbacks here, unsure if
>>> there is a use case).
>>>
>>> By reading the source it would appear that this is not really supported,
>>> or am I missing something ? (It would appear like I need some kind of
>>> ovverride in the TcpDiscoveryMulticastIpFinder#initializeLocalAddresses/
>>> U.resolveLocalAddresses
>>> area).
>>>
>>>
>>> Kristian
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>


-- 

Best regards,
Alexei Scherbakov

Re: Tcp discovery with clustered docker nodes

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, May 12, 2016 at 6:26 AM, Kristian Rosenvold <kr...@apache.org>
wrote:

> To ny understanding no; the java process running innside the docker
> container has no possibility of binding to the externally visible ip/port.
>
I think if you add “—net=host” parameter to your docker script, then docker
will allow binding to an externally visible port, like discussed in this
example:

https://apacheignite.readme.io/docs/docker-deployment#example

Re: Tcp discovery with clustered docker nodes

Posted by Kristian Rosenvold <kr...@apache.org>.
To ny understanding no; the java process running innside the docker
container has no possibility of binding to the externally visible ip/port.

Kristian
12. mai 2016 3.22 p.m. skrev "Alexei Scherbakov" <
alexey.scherbakoff@gmail.com>:

> Hi,
>
> TcpDiscoverySPI has two properties(localAddress and localPort), which
> allows you to set local address and port for Discovery SPI to bind.
> T
> Does it solve your problem?
>
>
> .
>
>
> 2016-05-12 10:56 GMT+03:00 Kristian Rosenvold <kr...@apache.org>:
>
>> We have been using jdbc based discovery successfully, but have been
>> trying to get this to work with docker. The problem is of course that all
>> the internal IP's inside the docker container are useless, so we'd really
>> need some way to override the discovery mechanism. Now you could of course
>> say that I should be using the static mechanism, but configuration-wise it
>> makes things really messy.
>>
>> It would be much cleaner to simply make each node publish its "correct"
>> external address to the discovery api, so that the JDBC discovery mechanism
>> would contain only the external address (ignoring loopbacks here, unsure if
>> there is a use case).
>>
>> By reading the source it would appear that this is not really supported,
>> or am I missing something ? (It would appear like I need some kind of
>> ovverride in the TcpDiscoveryMulticastIpFinder#initializeLocalAddresses/
>> U.resolveLocalAddresses
>> area).
>>
>>
>> Kristian
>>
>>
>>
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>

Re: Tcp discovery with clustered docker nodes

Posted by Alexei Scherbakov <al...@gmail.com>.
Hi,

TcpDiscoverySPI has two properties(localAddress and localPort), which
allows you to set local address and port for Discovery SPI to bind.
T
Does it solve your problem?


.


2016-05-12 10:56 GMT+03:00 Kristian Rosenvold <kr...@apache.org>:

> We have been using jdbc based discovery successfully, but have been trying
> to get this to work with docker. The problem is of course that all the
> internal IP's inside the docker container are useless, so we'd really need
> some way to override the discovery mechanism. Now you could of course say
> that I should be using the static mechanism, but configuration-wise it
> makes things really messy.
>
> It would be much cleaner to simply make each node publish its "correct"
> external address to the discovery api, so that the JDBC discovery mechanism
> would contain only the external address (ignoring loopbacks here, unsure if
> there is a use case).
>
> By reading the source it would appear that this is not really supported,
> or am I missing something ? (It would appear like I need some kind of
> ovverride in the TcpDiscoveryMulticastIpFinder#initializeLocalAddresses/U.
> resolveLocalAddresses
> area).
>
>
> Kristian
>
>
>
>


-- 

Best regards,
Alexei Scherbakov

Re: Tcp discovery with clustered docker nodes

Posted by Alexei Scherbakov <al...@gmail.com>.
Sorry, previous message was incomplete.

TcpDiscoverySPI has two properties(*localAddress *and *localPort*),
allowing you to set local address and port for Discovery SPI to bind.
These properties will be published by JDBC discovery manager in *shared *
mode.
Does it solve your problem?

2016-05-12 10:56 GMT+03:00 Kristian Rosenvold <kr...@apache.org>:

> We have been using jdbc based discovery successfully, but have been trying
> to get this to work with docker. The problem is of course that all the
> internal IP's inside the docker container are useless, so we'd really need
> some way to override the discovery mechanism. Now you could of course say
> that I should be using the static mechanism, but configuration-wise it
> makes things really messy.
>
> It would be much cleaner to simply make each node publish its "correct"
> external address to the discovery api, so that the JDBC discovery mechanism
> would contain only the external address (ignoring loopbacks here, unsure if
> there is a use case).
>
> By reading the source it would appear that this is not really supported,
> or am I missing something ? (It would appear like I need some kind of
> ovverride in the TcpDiscoveryMulticastIpFinder#initializeLocalAddresses/U.
> resolveLocalAddresses
> area).
>
>
> Kristian
>
>
>
>


-- 

Best regards,
Alexei Scherbakov