Resolve default daemon endpoint like the docker CLI (DOCKER_HOST + contexts)

[ebriney]

@

What

Makes the parameterless DockerClientConfiguration() resolve the Docker daemon endpoint the same way the docker CLI does, instead of jumping straight to the platform default socket.

Resolution order (new DockerContextResolver):

1. DOCKER_HOST environment variable (DOCKER_TLS_VERIFY upgrades tcp:// to https://)
2. Docker context — DOCKER_CONTEXT env var, or currentContext from ~/.docker/config.json, looked up under ~/.docker/contexts/meta/<sha256(name)>/meta.json
3. Platform default socket — unix:/var/run/docker.sock on Linux/macOS, npipe://./pipe/docker_engine on Windows

DOCKER_CONFIG is honored to override the config directory. Paths derive from the user profile, so the same code works on Linux, macOS, and Windows.

Also

• DockerClientConfiguration.FromContext(name, ...) for targeting a named context explicitly. It composes with the existing credential types (CertificateCredentials, BasicAuthCredentials, ...) just like the regular constructor.
• ssh:// endpoints are now rejected with a clear NotSupportedException that points users at an SSH tunnel + DOCKER_HOST, rather than the generic "Unknown URL scheme" error.
• README Usage section split into three subsections: default client (env → context → platform default), an explicit endpoint, and FromContext.

Tests

Adds DockerContextResolverTests covering DOCKER_HOST, TLS upgrade, context lookup, DOCKER_CONFIG override, and platform defaults.

Compatibility

The parameterless constructor previously always returned the platform default socket. Callers in environments with DOCKER_HOST/contexts set will now connect where the docker CLI connects. Explicit-endpoint constructors are unchanged.

🤖 Generated with Claude Code
@

[ebriney]

@dotnet-policy-service agree company="Docker"

[HofmeisterAn]

@ebriney This repo is inactive, we forked it some time ago and maintaining it.

We introduced a new DockerClientBuilder, and I think it would be great if it could take the environment into account automatically. We also use these variables in our tests.

Happy to review the PR if you're interested in contributing.

[ebriney]

@HofmeisterAn, thanks. So, do you want me to do a PR in https://github.com/testcontainers/Docker.DotNet?

[HofmeisterAn]

@HofmeisterAn, thanks. So, do you want me to do a PR in https://github.com/testcontainers/Docker.DotNet?

@ebriney This repo (https://github.com/dotnet/Docker.DotNet) has been inactive for about two years. No PRs have been merged, and the last release was in May 2023. I doubt this change will make it into main.

If you want these changes in the maintained and up-to-date version of Docker.DotNet, yes. But you'll need to adapt them to the newer client implementation since quite a few things have changed.

[ebriney]

@HofmeisterAn : opened and tested testcontainers#108