Docker-in-docker confuses getContainerIpAddress

[Zetten]

I'm using testcontainers in a CI environment, where the rest of the build is itself running inside a Docker container. By having Jenkins mount /var/run/docker.sock into the container, it's possible for the in-container environment to access the docker-engine running on the host. Since our application under development is itself working with Docker for some stuff, this works great for our existing tests, e.g. building and starting containers using docker-java.

I'm also adding testcontainers to support higher-level integration testing using docker-compose. This is working fine when run directly on the host system, but our tests fail when run in the docker-in-docker environment.

The issue seems to be with the ambassador container, and that running in this environment returns the wrong host/IP when calling org.testcontainers.containers.DockerComposeContainer#getServiceHost.

Basically because this calls through to DockerClientFactory.instance().dockerHostIpAddress() it is actually just returning the location of the docker-engine, and in the Unix socket environment it shortcuts to localhost (in org.testcontainers.dockerclient.DockerClientConfigUtils#getDockerHostIpAddress). But of course in docker-in-docker localhost doesn't resolve to the correct host/interface on which the ambassador container is listening.

I'm not sure what the best solution would be... I managed to debug and try a few things which seemed to work in principle (e.g. inject as the host IP address the default gateway IP as seen inside the container, or the IP of the docker0 interface on the host) but I'm sure there's a "right" way to go about it.

[bsideup]

Hey @Zetten,

I have a solution already, will backport it to TestContainers really soon, thanks for reporting!

Default gateway indeed the way to go, so I'll make TC detect docker-in-docker automatically

[Zetten]

Great stuff! I'm really happy with what I've used of TestContainers - and a quick response to issues is cool too. I eagerly await the next release 😄

[bsideup]

@Zetten FYI I submitted a PR with a fix.
It's not merged yet, but you can try it already, thanks to JitPack:

Add Jitpack's repo:

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

Use it:

<dependency>
    <groupId>com.github.testcontainers.testcontainers-java</groupId>
    <artifactId>testcontainers</artifactId>
    <version>docker-in-docker-SNAPSHOT</version>
</dependency>

Or just wait until it's merged :)

[Zetten]

@bsideup I've given the snapshot a test and it works perfectly!

What's the expected timeframe for the next release? Just roughly for planning future work - should we expect days/weeks/months?

[bsideup]

@Zetten we started to prepare 1.1.8; you can track the progress here:
https://github.com/testcontainers/testcontainers-java/milestone/19

IMO it's "days". Maybe even this week!

We plan some massive refactorings for 2.0 and would like to clean up all leftovers from 1.x, including this one :)

[bsideup]

@Zetten FYI it's also possible to run your tests with --net=host if it's acceptable :)