A way to tell the plugin to look at localhost for health checks.

[antony]

Hi,

I've been using your plugin for a while, very successfully on CircleCI 1.0

However, we're now moving to CircleCI 2.0 which doesn't allow you to run your own docker instance - instead, it runs a remote one for you and when you compose containers, they run on a remote host.

The problem is, the build itself on CircleCI also runs in a docker container, and that container cannot directly reach the remote docker host. What happens is that CircleCI binds all exposed ports to the build container.

As a result my healthcheck output is as follows:

> Building 50% > :composeUpProbing TCP socket on 35.190.191.100:3002 of service 'api'
Waiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))
> Building 50% > :composeUpWaiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))
> Building 50% > :composeUpWaiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))
> Building 50% > :composeUpWaiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))
> Building 50% > :composeUpWaiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))
> Building 50% > :composeUpWaiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))
> Building 50% > :composeUpWaiting for TCP socket on 35.190.191.100:3002 of service 'api' (Connection timed out (Connection timed out))

So the plugin correctly detects the remote host, but isn't aware that CircleCI has made the service TCP ports accessible on 'localhost' instead.

Looking at the source, I can't see a way to tell the plugin:

detect the remote docker instance, but expect the ports to be bound on xxx.yyy (or localhost)

I'm wondering about turning the healthcheck off and doing it manually for now, but it's not ideal.

[augi]

Hi, the waiting for exposed TCP ports opening can be turned off using waitForTcpPorts (I've added it to the README now).

As CirceCI could be common use-case I would prefer to solve this issue by detection of CirceCI environment (CIRCLECI envvar), and so adjust the Docker Host settings if CirceCI is detected. The check should be in this method

I read the documentation and I'm not sure if just changing to localhost would solve your problem. The documentation explicitly states this: Therefore, Docker or Machine containers cannot directly communicate with the containers running in remote docker.

So it doesn't make any sense to execute docker-compose in the primary container because the executed services wouldn't be accessible from the primary container. The documentation doesn't says anything about exposing the TCP ports back to the primary container.

So the recommendation is to execute also the Gradle build in the remote Docker - then it should work as usual.

Or do you have any other idea how to solve it?

[antony]

Thanks for that!

So the documentation on CircleCI is a little misleading. The containers run by circleci aren't accessible over TCP, but their ports are bound to the build container - so I can run a database container using CircleCI and my applications can access it.

But - if I run a docker container as part of my build, IT can't see those containers.

So what I'm doing is composing my DB, API, and Client inside my build container, so they can talk to eachother quite happily

The caveat here is that they run on a remote host (thanks to the way CircleCI works), so whilst they can see eachother, I can only access their TCP ports on "localhost" as viewed from my build.

So what I was thinking is here:

gradle-docker-compose-plugin/src/main/groovy/com/avast/gradle/dockercompose/tasks/ComposeUp.groovy

Line 217 in ce2e78c

def host = dockerHost.toURI().host ?: 'localhost'

Splitting the concept of DOCKER_HOST and SERVICE_HOST, if SERVICE_HOST is defined. Which I think its fine because there is no rule to say that services are always exposed on the DOCKER_HOST.

What this would mean is that I could specify:

DOCKER_HOST=tcp://xxx.yyy.zzz.qqq # defined by CIRCLECI
SERVICE_HOST=localhost # defined by me.

in my build, so that checks and system properties relating to containers could use SERVICE_HOST, if available.

What do you think?

[augi]

I like the idea of separation of DOCKER_HOST and SERVICE_HOST. The last problem we must handle is to choose to right port to use.

It's defined in this code:

gradle-docker-compose-plugin/src/main/groovy/com/avast/gradle/dockercompose/tasks/ComposeUp.groovy

Line 254 in ce2e78c

switch (host.type) {

Can you please check how the ports are exposed? E.g. if a service exposes port 80 on port 8080, then the service is available on localhost:8080?

[antony]

That's right - it just uses the default port mappings :)

[augi]

So I prepared this PR. Could you please check if it's what you are expecting?

[antony]

You are a software machine! I'll have a look asap.

…

On Mon, 4 Sep 2017, 17:53 Michal Augustýn ***@***.***> wrote: So I prepared this PR <#98>. Could you please check if it's what you are expecting? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#97 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANXRbc_-BI2WRlbMmtIydZtcvilz3ZDks5sfCsKgaJpZM4PLsHj> .

[augi]

I will release a new version ASAP, it will be 0.5.2