Improve support for alternative container runtimes

[tjamet]

In several cases, alternative container runtimes offers a docker compatible API and populates the docker context accordingly.

However, in the current implementation of testcontainers, the context is often ignored as the EnvironmentAndSystemPropertyClientProviderStrategy only considers the DOCKER_HOST override either through testcontainers property or the environment variables.

Improve the support of multiple container runtimes by honoring the current docker context.

In addition, improve the detection of whether the Docker engine runs in a virtual machine without root access for the current user, so it removes the need to configure TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE in standard cases.

This change has been tested with:

• colima
• rancher desktop (in non-privileged mode)
• docker desktop
• orbstack

[eddumelendez]

Thanks for your contribution, @tjamet. Can you please run ./gradlew spotlessApply? or give me access to update the branch, please.

[kiview]

LGTM, we only need to check, whether this might accidentally break RootlessDockerClientProviderStrategy, since in this case, the socket might also be in the home directory, but should not resolve to /var/run/docker.sock for getRemoteDockerUnixSocketPath().

[kiview]

I think these docs can even be removed, to avoid confusion, right?
Same for the Podman and Rancher docs I guess?

[tjamet]

Happy to further remove the docs.
I think the podman one needs to stay. In my experience, rootless podman installation do not configure the Docker context

[tjamet]

I will check the rootless docker client strategy and find a way not to break it

[tjamet]

@kiview I've updated the PR taking your thoughts into considerations.

From my trials, the default behaviour for rootless docker containers is to create the docker socket inside XDG_RUNTIME_DIR (usually /var/run/${userID}, while mac os desktop providers creates the socket inside the user home directory.
Both initialised the Docker context.
This means that it is likely that most of the RootlessDockerClientProviderStrategy and DockerDesktopClientProviderStrategy start to use the EnvironmentAndSystemPropertyClientProviderStrategy.

This is what I see on a linux machine:

docker context ls
NAME         DESCRIPTION                               DOCKER ENDPOINT                     ERROR
default      Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
rootless *   Rootless mode                             unix:///run/user/1000/docker.sock

ls -al /run/user/1000/docker.sock
srw-rw---T 1 thibault thibault 0 Sep 25 09:52 /run/user/1000/docker.sock

And on a mac one:

docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT                                            ERROR
colima              colima                                    unix:///Users/thibault.jamet/.colima/default/docker.sock
default             Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux       Docker Desktop                            unix:///Users/thibault.jamet/.docker/run/docker.sock
orbstack            OrbStack                                  unix:///Users/thibault.jamet/.orbstack/run/docker.sock
rancher-desktop *   Rancher Desktop moby context              unix:///Users/thibault.jamet/.rd/docker.sock

ls -al /Users/thibault.jamet/.rd/docker.sock
srw-------  1 thibault.jamet  staff  0  9 Sep 13:19 /Users/thibault.jamet/.rd/docker.sock

With this in mind, I changed the approach to consider the socket is virtualised only if it is a unix socket inside the home directory
The previous change checking the user ID would indeed break the rootless Docker approach

[eddumelendez]

/windows-test

[kiview]

/windows-test