Issue when testcontainers is used from within a Docker container

[pbillen]

Hi all,

I am facing an interesting problem with testcontainers. I am using the DockerComposeContainer class to start a container for a docker-compose.yml configuration as following:

DockerComposeContainer c = new DockerComposeContainer(... path to docker-compose.yml ...).withLocalCompose(false);
c.starting(null);

Please note the withLocalCompose(false), as it is important.

This works great on my host. However, when my application is started in a docker container, this doesn't work. I am starting my container as following:

docker run -v /var/run/docker.sock:/var/run/docker.sock:ro my-image

Why?

In my-image, the docker-compose.yml is in /app. Now, when c.starting(null) is called, a new child docker-compose container is started, as per withLocalCompose(false). This container is executed in the host, as per -v /var/run/docker.sock:/var/run/docker.sock:ro. But, in my host, there is no /app/docker-compose.yml.

How can we solve this?

One possible solution might be to read and parse /app/docker-compose.yml before starting the child docker-compose container? Either this could be done by (ideally) testcontainers or by myself. In the case of the latter, I should be able to provide the contents of /app/docker-compose.yml to the constructor of DockerComposeContainer.

However, I am not sure if this is the best solution, as I don't have any idea if this is supported by components upstream.

Any ideas?

Thank you!

[bsideup]

Hi @pbillen,

Please read this page about staring the tests inside a Docker container:
https://www.testcontainers.org/usage/inside_docker.html

It seems that you're missing -v $PWD:$PWD -w $PWD

[pbillen]

Hi @bsideup,

Thank you for tuning in!

I actually thought about this and that will work if the docker-compose.yml is in the host, which is usually the case (that is, usually you are mounting a host directory to the container, as you are doing with -v $PWD:$PWD).

However, in my case, the docker-compose.ymlis not in the host, it is in an arbitrary directory /app in the container. It is part of image my-image. I would rather not mount /app on the host, as this will make it impossible to run several containers concurrently: my-image-2might have a different /app/docker-compose.yml than my-image.

That's why I thought about providing the contents of /app/docker-compose.yml to testcontainers instead of the location.

I hope this makes sense...

[kiview]

Yes, this is a problem with the current implementation, that's why we are using a local docker-compose at my workplace if used inside our (docker based) CI environment.

Another solution might involve dynamically creating volumes and mounting them at the appropriate locations. Not sure if the would overshadow the existing content though?

[pbillen]

Hi @kiview,

Thanks for your feedback.

Are there plans to support this flow? A local docker-compose would work indeed, but I believe it would be useful if we could remain using the dockerized docker-compose, so dependencies on the specific environment/usage remain not relevant. But good idea nonetheless, I will start using the local docker-compose on CI for now.

With regards to your alternative solution: that's a good idea. I will try this out in the next days. I will keep you updated.

Thanks again!

[kiview]

Hi @pbillen,

we are currently planning on rewriting the core of testcontainters to become JUnit4 independent (you can see the design progress here: rnorth/containercore#1). This will be part of testcontainers 2.0. I'm quite optimistic that we'll also be able to implement a more simple docker-compose integration to cater for such use cases.

Do you think we can close this issue or should we clarify something in the docs regarding your misunderstanding?

[pbillen]

Hi @kiview,

Testcontainer 2.0, interesting :). Already looking forward to it!

I think this issue can be closed, the docs are quite clear.

Thanks @kiview and @bsideup for feedback!