Testcontainers-java: Usage of DockerComposeContainer with remote docker daemon

[g8373653]

Hi all,

I am using DockerComposeContainer to deploy a custom docker-compose.yml, which describes the environment used during the integration tests. This has been working great so far. I recently started using a remote Docker daemon - instead of a local one - to execute certain integration tests remotely and I am running into problems with DockerComposeContainer.

My current challenge is that DockerComposeContainer accepts a File, the path to the docker-compose.yml. The problem with a remote Docker daemon is that a full path for <root path project>/src/test/resources/docker-compose.yml will fail to resolve on the host running the remote Docker daemon, as this path does not exist over there:

[INFO] Docker host IP address is 10.0.0.101
[INFO] Connected to docker: 
...
[INFO] Pulling docker image: alpine/socat:latest. Please be patient; this may take some time but only needs to be done once.
[INFO] Pulling docker image: docker/compose:1.21.0. Please be patient; this may take some time but only needs to be done once.
[INFO] Creating container for image: docker/compose:1.21.0
[INFO] Starting container with ID: bf33960e45ca4ce589860e6bde62fb85f8847e2f12516efd38ecd64073455915
[INFO] Container docker/compose:1.21.0 is starting: bf33960e45ca4ce589860e6bde62fb85f8847e2f12516efd38ecd64073455915
[ERROR] Could not start container
java.lang.IllegalStateException: Container did not start correctly.
    at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:272)
    at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:226)
    at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76)
    at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:224)
    at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:209)
    at org.testcontainers.containers.ContainerisedDockerCompose.invoke(DockerComposeContainer.java:556)
    at org.testcontainers.containers.DockerComposeContainer.runWithCompose(DockerComposeContainer.java:219)
    at org.testcontainers.containers.DockerComposeContainer.createServices(DockerComposeContainer.java:173)
    at org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:160)
    at org.testcontainers.containers.DockerComposeContainer.starting(DockerComposeContainer.java:129)
[ERROR] Container log output (if any) will follow:
[INFO] STDERR: .FileNotFoundError: [Errno 2] No such file or directory: '/home/doplon/projectabc/src/test/resources/docker-compose.yml'

I am looking for suggestions on how to proceed now.

• A feature/change request could be that DockerComposeContainer also accepts a String (instead of File), holding the contents of the docker-compose.yml file. That said, I am not sure what the implementation would look like, as there is an intermediate container responsible for booting up docker-compose.yml. Maybe the second approach is more feasible.
• Another feature/change request is to hold the docker-compose.yml in a temporary Docker volume. This way, the container responsible for booting up the docker-compose.yml can have a mount to the volume and can easily read it. Since the Docker volume will be created on the remote Docker daemon, the issue as explained above disappeared.
• Maybe there are other approaches which does not involve a change in Testcontainers's source?

Any feedback is very much appreciated. I'm certainly open to try or hack certain things out.

Please note I also asked the question here: https://stackoverflow.com/questions/51431279/usage-of-dockercomposecontainer-for-a-remote-docker-daemon

Thanks a lot!

[bsideup]

Hi @g8373653,

Try withLocalCompose(true) :)

[g8373653]

Hi @bsideup,

Thanks for pointer, it works indeed with withLocalCompose(true)!

I actually forgot about explaining that, but our goal is to get it working with withLocalCompose(false). The idea is that we spawn several Docker daemons and that's it. We would rather not install any other dependencies on the hosts, docker-compose included. Our network admin is really into the Docker only mindset, so he would rather not install docker-compose on the host(s) running Jenkins, if that makes sense.

So I am aiming for the best of both worlds:

• withLocalCompose(false)
• docker-compose.yml not on file system of the host running the docker-compose container

I am not really sure if this way of working doesn't make things more complicated, to tell you the truth.

[bsideup]

Well, then I would really suggest to use GenericContainers instead :) They give you the best of two :)

But if you really need to do that, you can use copyFileToContainer method to copy your compose file into compose container, it will use InputStream of it instead of mounting it as a file

[g8373653]

Thanks again!

There is some useful logic in DockerComposeContainer which I would need to re-invent if I start to use GenericContainer I guess. I think creating an alternative version of DockerComposeContainer.ContainerisedDockerCompose which makes use of that copyFileToContainer makes more sense, no?

[gclayburg]

I have the same issue, @g8373653 . I'd like to be able to use DockerComposeContainer during a Jenkins build where the build itself is running in a container. It looks like testcontainers doesn't really support that just yet as you pointed out. Have you had any luck with your suggestion?

Or maybe I'd be better off doing what @bsideup suggests? GenericContainer does work, but it would mean porting my docker-compose to that format.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[rnorth]

Let's keep this ticket open, as I think it _should_ be do-able.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[stale[bot]]

This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case.

[ryanesch]

@g8373653 did you ever resolve this?

[Bryksin]

The same problem, build runs inside gradle docker with mounted docker socket, so it should run TC in parallel, but test containers not finding compose file