the java-client seems to have DNS / lookup issues

[EugenMayer]

See this gocd-elastic-agent boilerplate

https://github.com/EugenMayer/gocd-boilerplate/blob/master/docker-compose.yml - all the issues here can be reproduced there.

When using a service name alias as a gocd-server URL: https://gocd-server:8154 .. the java client in the docker-container ( agent ) cannot look it up, while the docker-engine can do that just fine:

/ # nslookup gocd-server
nslookup: can't resolve '(null)': Name does not resolve

Name:      gocd-server
Address 1: 172.22.0.3 gocd_gocd-server_1.gocd_default
/ # ping gocd-server
PING gocd-server (172.22.0.3): 56 data bytes

which library is used for the DNS resolution?

[EugenMayer]

When i use the docker-machine ip as the gocd-server url configuration, it works - but this should not break in the first place. Inter-container communication is always happening using service aliases, so this should be working for us.

In addition:
its fairly inconvinient to run and ... i cannot create a boilerplate like that because i do not know the IP beforehand .. in addition d4m users will need to know how to create and interface alias to lo0 before the even can think about using it.. because localhost wont work anyway..so thats even worse then not being able to create such a test boilerplate, thats a for more technical detail for a user to understand

[EugenMayer]

this could be very much related to https://forums.docker.com/t/resolved-service-name-resolution-broken-on-alpine-and-docker-1-11-1-cs1/19307/21 - which would be rather either a did bug ( since its based on alpine ) or an alpine bug soley

[EugenMayer]

thats a total different issue in the end moby/moby#23910

it basically because on d4m 127.0.0.x is used for dns resolving, which is an issue when you nest docker-in-docker.

Closing that issue, has nothing to do with elastic-agent or java in general, sorry