"Universal" connection method?

[stuhood]

As described in https://github.com/pantsbuild/pants/issues/18889, it seems like our initial use of the crate ended up hardcoding a single DOCKER_HOST handling mechanism, since there isn't a single Docker::connect_with_* method that would handle all of the possible socket types for DOCKER_HOST.

It seems like it is nearly possible to create a Docker::connect_with_defaults() method which would rely on DOCKER_HOST parsing to distinguish between connection types. Except that as that ticket mentions (based on the dockerd docs) I don't see how to determine that Docker::connect_with_ssl_defaults() is necessary given only the connection string.

[fussybeaver]

I'm open to adding/modifying the functionality that will determine the correct connection mechanism using an environment variable (as long as we retain backward compatibility). The original functionality for using the DOCKER_HOST env variable is quite old and wasn't fleshed out, because the primary focus for the library wasn't to mimic the docker CLI. I don't think we need to comply 100% to the docker CLI here - for example, I think it'd be fine to source the SSL connection using an https://... prefix to the DOCKER_HOST environment variable, since that's what hyper expects.

[jalaziz]

For reference, this is how the Docker CLI determines which method to use. For TLS, it seems like it requires TLS options (CA cert, key file, etc) to be provided.

There's also the DOCKER_TLS_VERIFY env var.