feat: Resolve default Docker endpoint like the Docker CLI#108
Conversation
Resolves the Docker daemon endpoint the same way the docker CLI does,
in this order:
1. DOCKER_HOST environment variable (DOCKER_TLS_VERIFY upgrades
tcp:// to https://)
2. 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 are
derived from the user profile so the same code works on Linux, macOS,
and Windows.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The parameterless DockerClientBuilder() now uses DockerContextResolver instead of jumping straight to the platform default socket, so it transparently honors DOCKER_HOST and the active Docker context just like the docker CLI. Add DockerClientBuilder.WithContext(string) to target a named Docker context explicitly. Also give ssh:// its own branch in ResolveTransportFactory with actionable guidance, instead of the generic unsupported-scheme error, since SSH-based contexts are now reachable through the resolver. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous parser required exactly three Uri segments with "pipe/" at index 1, and failed on the canonical form docker contexts store on Windows, "npipe:////./pipe/docker_engine", which parses with an empty Host and an extra leading path segment. Search for the "pipe/" segment instead of indexing it, and fall back to the segment before "pipe/" for the server name when the Host is empty. Empty / "localhost" server names still resolve to "." so NamedPipeClientStream can connect. Handles both URI shapes that the docker CLI emits: npipe://./pipe/docker_engine npipe:////./pipe/docker_engine Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Split the Usage section into the default client (env -> context -> platform default), an explicit endpoint, and DockerClientBuilder .WithContext for targeting a named context. Adds a note that ssh:// endpoints are not supported. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The parameterless DockerClientBuilder constructor now resolves the endpoint CLI-style via DockerContextResolver.Resolve(), so the test must neutralize DOCKER_HOST/DOCKER_CONTEXT/DOCKER_TLS_VERIFY and point DOCKER_CONFIG at an empty directory for the platform default to be selected. Without this, the test failed on any machine with an active non-default Docker context (e.g. desktop-linux). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thanks for the PR. I'll do the review sometime end of the week. |
|
Thanks again for the PR. While reviewing it, I noticed that much of it overlaps with functionality we already have in Testcontainers and that I've wanted to move into Docker.DotNet for a while. I copied the Testcontainers implementation, made a few adjustments, and improvied testing for different configurations. We can also add proper TLS support later by reusing the Testcontainers implementation. I'd like to do one final review, but if you're happy with the changes, I'm happy to merge them and publish a new version. WDYT? Edit: I'll look into the failing tests. This was expected, as we've already set the |
I verified your commits and it is working well on windows and mac. |
HofmeisterAn
changed the title
2 participants
Summary
new DockerClientBuilder()resolve the daemon endpoint the same way thedockerCLI does:DOCKER_HOST→ active Docker context (DOCKER_CONTEXT/currentContextin~/.docker/config.json) → platform default socket. Works the same on Linux, macOS, and Windows.DockerClientBuilder.WithContext(name)to target a named Docker context explicitly. Endpoint is read from~/.docker/contexts/meta/<sha256(name)>/meta.json(honorsDOCKER_CONFIG).npipe://URI parsing so the four-slash form docker contexts emit on Windows (npipe:////./pipe/docker_engine) is accepted alongside the existingnpipe://./pipe/docker_engineform.ssh://its own branch with actionable guidance instead of the generic unsupported-scheme error, since SSH-based contexts are now reachable through the resolver (recommend an SSH tunnel +DOCKER_HOST).Test plan
DockerClientBuilderTestscovering env-var, context, and platform-default resolutionConstructor_SetsPlatformDefaultEndpointisolated from the host'sDOCKER_*env and~/.docker/config.jsonso it passes on machines with an active non-default contextnew DockerClientBuilder().Build()connects against Docker Desktop on macOS (desktop-linuxcontext) and Windows (named pipe) with no explicit URI