Remote docker-host and non-SSL-setup

[jarmoni]

I exported environment-variable DOCKER_HOST as described (Port 2375 -> no SSL):

➜  ~  echo $DOCKER_HOST
tcp://192.168.33.10:2375
➜  ~

This worked for months in version 0.2.11 but in 0.4.0 it seems to be broken. The plugin tries to connect via SSL and this (of course) fails:

[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.4.0:build (default) on project service-cache: Exception caught: java.util.concurrent.ExecutionException: com.spotify.docker.client.shaded.javax.ws.rs.ProcessingException: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? -> [Help 1]

When I set config-property 'dockerHost' in the plugin's config <dockerHost>tcp://192.168.33.10:2375</dockerHost>, I get:

[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.4.0:build (default) on project service-cache: Exception caught: An HTTPS URI for DOCKER_HOST must be provided to use Docker client certificates -> [Help 1]

There are no additional env-variables like DOCKER_CERT_PATH or DOCKER_TLS_VERIFY exported in my environment. So I don't know why the plugin assumes that I use SSL

[mattnworb]

Looks like the issue is that AbstractDockerMojo calls DefaultDockerClient.fromEnv() which defaults to setting a certificate path of System.getProperty("user.home") + ".docker" with no way of overriding the logic or specifying your own DefaultDockerClient.Builder.

[nodje]

v0.3.7 seem to also have the problem.
This tag doesn't exist in the github project but the Maven artifact is available.
It's using docker-client v3.3.1.

It'd be nice to know what is the latest version that does't have the problem.

[volyx]

+1

[laurent-opnworks]

To use docker:build on my local workstation with a docker daemon not using TLS, I temporarily renamed the folder "/.docker" to "/.docker.tmp" and used unix:///var/run/docker.sock in the plugin configuration.

Surprise: I got a BUILD SUCCESS!

This would confirm mattnworb 's hypothesis. Obviously not a very practical solution but an interesting result.

[marcellodesales]

@mattnworb Any workaround for this? I'm coming from #221 and #222

[marcellodesales]

@laurent-opnworks what version were you using? I tried your workaround and did not get anywhere...

[laurent-opnworks]

@marcellodesales I believe it was docker v1.10 and docker-maven-plugin v0.3.258 but I have not pursued my investigations since then. Still hoping/waiting for a "real" solution.

[davidxia]

@mattnworb How does #216 look as a solution? It seems pretty good to me.

[mattnworb]

DefaultDockerClient.fromEnv() in docker-client will configure the DockerClient to use a set of certificates if the path pointed to by DOCKER_CERT_PATH or ~/.docker exists and if each of ca.pem, cert.pem and key.pem exists in that directory (see here, here and here).

@laurent-opnworks do you have files in this path even though your docker daemon does not use TLS?

[mattnworb]

On the other hand, this check in docker-client doesn't really need to be there

if ((builder.dockerCertificates != null) && !originalUri.getScheme().equals("https")) {
  throw new IllegalArgumentException(
      "An HTTPS URI for DOCKER_HOST must be provided to use Docker client certificates");
}

as the class takes care elsewhere not to assume that builder.dockerCertificates is non-null if the URI is https.

[mattnworb]

Sorry, my previous comment is false. DefaultDockerClient uses the presence of the DockerCertificates class to determine if it should use http or https to communicate with the Docker Remote API to talk to the daemon (when the DOCKER_HOST or .dockerHost(..) values does not start with unix://).

This seems like a fair assumption to make since the DOCKER_HOST format generally starts with tcp:// regardless of whether or not TLS is used.

Another way for the DefaultDockerClient to tell if it should use https or http could be to look at the port portion of the URI in DOCKER_HOST, since conventionally 2375 is for non-TLS and 2376 is for TLS connections; however, since you could in theory configure your daemon to use any port you want whether or not TLS is enabled, this seems like it would be a worse condition to base logic off of.

It might make more sense to add a flag like boolean tlsEnabled to the DockerClient and to this plugin, to use in deciding to use https or http, rather than the presence of these certificate files. This is more or less how the docker CLI client and daemon work.

But for a workaround today, you could remove the certs in ~/.docker if you do not intend for the plugin to use TLS.

[marcellodesales]

@mattnworb I'm thinking how this would work in a CI server... Changing the ~/.docker directory may affect other docker calls in the host, right? That just doesn't sound that great... I agree with your assessment in regards to the boolean tlsEnabled, since it indicates the true desire of the plugin's user.