Problem

I'm currently working on Sablier and this project needs to interact with a Docker host.
It can list, start and stop containers.

Interacting with direct socket may cause some issues: the workspace is polluted with my containers, and I don't want that.

So I've though of using a Docker in Docker container as my sandbox for my test.

Testcontainers does not enable me to spawn a Docker in Docker container to make subsequent request to it.
The current Docker host detection does not allow you to have multiple docker daemon.

Here's my sample:

// This create a Docker in Docker container and returns me 
// a docker client. This container is created with testcontainers.
cli, err := NewDind()
if err != nil {
t.Error(err)
}

// My app API that uses the client
p, err := SablierAPI(cli)
if err != nil {
t.Error(err)
}

// Tried to dynamically make requests using the rule `3.` for Docker host detection, does not work
ctx := context.WithValue(context.Background(), "DOCKER_HOST", cli.DaemonHost())

// Create multiple containers using testcontainers targeting the 
c, err := createRunningContainer(ctx)
...

And I though that Docker host detection rule 3 would actually make the trick.

3. Read the Go context for the DOCKER_HOST key. E.g. ctx.Value("DOCKER_HOST"). This is used internally for the library to pass the Docker host to the resource reaper.

But it turns out that it does not for multiple reasons:

1. The context is not propagated to the provider (on purpose ?)
   When issuing creation request, the provider itself uses a new blank context:

2. The docker host is cached

3. The context docker_host is overriden with the one from the provider

Solution

The solution would be to be for testcontainers to be able to pick up multiple containers and fully propagate the docker host at every call.

3. Read the Go context for the DOCKER_HOST key. E.g. ctx.Value("DOCKER_HOST"). This is used internally for the library to pass the Docker host to the resource reaper.

So that this would be dynamic, it must not be cached.

Benefit

This would allow applications that tests docker interactions to work properly by using testcontainers features.

Alternatives

I could create the Docker in Docker container myself first, but it would defeat the original purpose of testcontainers in my opinion.

Would you like to help contributing this feature?

Yes