Can't connect to Ryuk when using when running in container and using Docker-Socket-Mounting on Docker Desktop

[jrussellsmyth]

When running testcontainer based test within another container (vscode devcontainer)

Tests that executed flawlessly on 1.15.3 now fail attempting to start the compose configuration

java.lang.IllegalStateException: Could not connect to Ryuk at 172.17.0.1:58364
at org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:227) ~[testcontainers-1.16.0.jar:?]
at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:204) ~[testcontainers-1.16.0.jar:?]
at org.testcontainers.containers.DockerComposeContainer.(DockerComposeContainer.java:135) ~[testcontainers-1.16.0.jar:?]
at org.testcontainers.containers.DockerComposeContainer.(DockerComposeContainer.java:119) ~[testcontainers-1.16.0.jar:?]

We did attempt disabling Ryak, but that just results in the same error attempting to connect to the first container.

Docker Desktop 3.6.0
macOS Mojave version 10.14.6
intel mac

[jrussellsmyth]

Created a minimal test case for this here demonstrating expectations with 1.15.3 and failure with 1.16.0
https://github.com/jrussellsmyth/testcontainer-problem

[kiview]

Hi @jrussellsmyth,
thanks a lot for reporting this issue and providing us with a reproducer.

This problem also occurs on Windows in WSL2. In addition, it also happens with GenericContainer. Therefore, I assume this has nothing to do with DockerComposeContainer or Docker for Mac and it seems there is a regression in 1.16.0 for the Docker Wormhole Pattern (i.e., socket mounting) in general.

[Nayshins]

Is there a timeline for this to be fixed? I'm stuck in a bit of a bind here of needing to be on 1.16.+ for M1 support, but this issue is blocking me from using this version with docker for mac.

If anyone has a suggestion for a workaround that would be greatly appreciated!

[kiview]

No ETA yet, see the PR #4396 and the possible implications from upstream Docker here:
docker/for-mac#5588 (comment)

What is your use case for running the tests inside of Docker Compose in the first place? Maybe if we think about this, we can come up with a workaround or alternative setup.