Dockerfile-maven: Docker authentication to private registry fails since 1.3.4
I have upgraded to 1.3.4 to benefit from the flag googleContainerRegistryEnabled, but I encounter the following exception:
[ERROR] Failed to execute goal com.spotify:dockerfile-maven-plugin:1.3.4:push (push-docker-image) on project sample: Could not push image: no basic auth credentials -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.spotify:dockerfile-maven-plugin:1.3.4:push (push-docker-image) on project sample: Could not push image
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.jvnet.hudson.maven3.launcher.Maven33Launcher.main(Maven33Launcher.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at jenkins.maven3.agent.Maven33Main.launch(Maven33Main.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:139)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.maven.plugin.MojoExecutionException: Could not push image
at com.spotify.plugin.dockerfile.PushMojo.execute(PushMojo.java:90)
at com.spotify.plugin.dockerfile.AbstractDockerMojo.tryExecute(AbstractDockerMojo.java:227)
at com.spotify.plugin.dockerfile.AbstractDockerMojo.execute(AbstractDockerMojo.java:216)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 31 more
Caused by: com.spotify.docker.client.exceptions.DockerException: no basic auth credentials
at com.spotify.plugin.dockerfile.LoggingProgressHandler.handleError(LoggingProgressHandler.java:105)
at com.spotify.plugin.dockerfile.LoggingProgressHandler.progress(LoggingProgressHandler.java:63)
at com.spotify.docker.client.ProgressStream.tail(ProgressStream.java:74)
at com.spotify.docker.client.DefaultDockerClient.push(DefaultDockerClient.java:1291)
at com.spotify.docker.client.DefaultDockerClient.push(DefaultDockerClient.java:1271)
at com.spotify.plugin.dockerfile.PushMojo.execute(PushMojo.java:88)
... 35 more
I have a quite standard config.json:
{
"auths": {
"nexus.localdomain:5000": {
"auth": "hashedPwd"
},
"nexus.localdomain:5001": {
"auth": "hashedPwd"
}
}
}
I have also tested with a duplicated one like below with and without protocols as I stumbled on old issues linked to that problem, but with no more success, idem with only protocol suffixed ones:
{
"auths": {
"http://nexus.localdomain:5000": {
"auth": "hashedPwd"
},
"http://nexus.localdomain:5001": {
"auth": "hashedPwd"
},
"nexus.localdomain:5000": {
"auth": "hashedPwd"
},
"nexus.localdomain:5001": {
"auth": "hashedPwd"
}
}
}
I thinks that it is linked to the upgrade of the Docker client from 8.8.0 to 8.8.1 introduced by c295836810b9ad80c00361daf3bcf702d967e2d0 to resolve #23. I suspect more specifically the commit https://github.com/spotify/docker-client/commit/c29e44bc986d108b40862ee0b540b7a943f9c424.
stephanedaviet
All 25 comments
Got the same issue and this bug report was the hint for the workaround:
I duplicated my auths entry (which was without https:// prefix) and added the https prefix.
@stephanedaviet: you should try httpS instead http.
This has to be like that because of the code in line 108-110 at ImageRef where https is added if no protocol is specified.
In case your repo is not available with https, it might be another workaround to set the repository setting at your pom to the http-URL.
I think adding a protocol by default is not a good idea. I used docker login with a https-URL and it got stored at config.json without protocol prefix.
rudibatt
on 21 Aug 2017
Small problem, we haven't HTTPS on the target internal server :-/. I am hardly working to get it set up. Thanks for the hint though.
stephanedaviet
on 21 Aug 2017
+1
Using an unsecured private Nexus 3 (http).
I had to go back to v1.3.3 (and ~/.docker/config.json without transfer protocol)
Authentication failed with v1.3.4 and v1.3.5
ldebs
on 24 Aug 2017
+1
Using an amazon container registry and auth failed with the above error for 1.3.5. Rolling back to 1.3.3 worked.
bigtoast
on 2 Sep 2017
+1
I'm using Jenkins pipeline withDockerRegistry with Nexus3 private http repository. This issue is realling disturbing my builds.
bkmeneguello
on 2 Sep 2017
Same issue here using Gitlab CI build pipelines as well.
I'll stick with version 1.3.3 for now otherwise my build will break...
j-tim
on 23 Sep 2017
1.3.6 with settings.xml server authentication works very well for me.
Em 23 de set de 2017 16:31, "Tim van Baarsen" notifications@github.com
escreveu:
Same issue here using Gitlab CI build pipelines as well.
I'll stick with version 1.3.3 for now otherwise my build will break...—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/spotify/dockerfile-maven/issues/62#issuecomment-331664874,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQuOOuPcJEGk8BLdWip0ah1UeSzHd-Rks5slVyHgaJpZM4O4_xL
.
bkmeneguello
on 23 Sep 2017
+1
We're using AWS ECR, doing eval $(aws ecr get-login ...) prior to mvn deploy and get the same error with 1.3.6. Tried 1.3.3 as suggested by @bigtoast and this works.
nahguam
on 5 Oct 2017
so the thing looks really broken.
Requiring a dot in the hostname is something that should be documented.
The first piece of software stopping to work with simple hostnames....
(Considering the original spotify use cases this is understandable though.)
But then it becomes impossible when using local insecure-registries.
Which I think makes totally sense in networks without an internet connection!
If I specify the protocol the ImageRef parser fails. and returne docker.io as the registry!!!
If I dont specify the protocol HTTPS get chosen as a fallback for the failed parsing ....
so no way to get this going.
I try maven auth now.
NOPE. Not helping past the protocol problem :(
uvwild
on 6 Dec 2017
So I found a super messy workaround:
I still can use the simple host insecure docker registry (our local nexus server).
BUT I need to add a fake authentication line to the .docker/config.json by copying the authentication line from the real server and replacing the host with the default docker repo like so:
"auths": {
"my-local-nexus-host": {
"auth": "XXXXXXXXXXXXXXXXXXX"
},
"https://index.docker.io/v1/": {
"auth": "XXXXXXXXXXXXXXXXXXX"
},
}
Same problem for me, I stick to 1.3.3 until it is solved.
res1st
on 21 Dec 2017
This is fixed in the docker-client library in newer versions. You can force the dependency in the plugin like this :
```
...
mryan43
on 9 Jan 2018
I use gitlab-ci and sonatype nexus 3, dockerfile 1.3.6
Thanks to @mryan43 for the docker-client hint
secret variables are defined in gitlab: DOCKER_PUSH_USER and DOCKER_PUSH_PASS
I know the excerpt below is not MWE, but maybe it still helps someone to work around this issue
.gitlab-ci.yml:
build:
image: openjdk:8-jdk
stage: build
script:
- ./mvnw -B -s .ci/settings.xml clean install deploy site-deploy
.ci/settings.xml
<servers>
<server>
<!-- for docker push -->
<id>docker.nexus.somewhere</id>
<username>${env.DOCKER_PUSH_USER}</username>
<password>${env.DOCKER_PUSH_PASS}</password>
</server>
</servers>
pom.xml
<project>
<build>
<plugins>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>1.3.6</version>
<executions>
<execution>
<id>default</id>
<goals>
<goal>build</goal>
<goal>push</goal>
</goals>
<configuration>
<tag>${project.version}</tag>
</configuration>
</execution>
<execution>
<id>push-as-latest</id>
<configuration>
<tag>latest</tag>
</configuration>
<goals>
<goal>build</goal>
<goal>push</goal>
</goals>
</execution>
</executions>
<configuration>
<repository>docker.nexus.somewhere/someone/something</repository>
<buildArgs>
<JAR_FILE>${project.build.finalName}.jar</JAR_FILE>
</buildArgs>
<useMavenSettingsForAuth>true</useMavenSettingsForAuth>
</configuration>
<dependencies>
<!-- from https://github.com/spotify/dockerfile-maven/issues/62#issuecomment-356368099 -->
<dependency>
<groupId>com.spotify</groupId>
<artifactId>docker-client</artifactId>
<classifier>shaded</classifier>
<version>8.11.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>
helt
on 5 Feb 2018
The issue still exists at 1.3.7, even with the docker config without https/http. The aforementioned version (1.3.3) works as expected without any changes in Docker client.
lazam
on 23 Feb 2018
Thanks @lazam for the workaround.
I confirm that works with 1.3.3 and does not work with 1.3.7
codingtony
on 24 Feb 2018
had to revert to 1.3.3 to use AWS again as well.
nick-wellinghoff-sp
on 21 Mar 2018
Forcing the plugin to use docker client latest release (8.11.2) fixed ecr login issues to me
mmiglier
on 21 Mar 2018
@mmiglier Were you successful shading to the 8.11.2 docker client using plugin version 1.4.0 or an older version?
tschutte
on 9 Apr 2018
Using 1.4.0
Il giorno 09 apr 2018, alle ore 23:03, Terry Schutte notifications@github.com ha scritto:
@mmiglier Were you successful shading to the 8.11.2 docker client using plugin version 1.4.0 or an older version?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
mmiglier
on 10 Apr 2018
Thanks. Seems none of these combinations are working for me on 1.4.0 and newer docker clients (on linux). For now I've successfully reverted to 1.3.3 as well.
tschutte
on 10 Apr 2018
@nahguam How did you get the container to execute the AWS commands? Did you map the hosts /usr/bin into the container's filesystem? I'm running Jenkins on an EC2 host that's instantiated with the aws-cli and python - but the build-executor container won't pick up my "-v" mappings.
The Jenkinsfile agent is
agent {
docker {
image 'maven:3-alpine'
// TODO Don't run builds as root -
args '-v /var/lib/jenkins/.m2:/var/lib/jenkins/.m2 -v /tmp:/tmp -v /var/run/docker.sock:/var/run/docker.sock ' +
' -v /etc/passwd:/etc/passwd -v /etc/group:/etc/group ' +
' -v /usr/bin:/usr/local/docker/usr/bin -v /opt/aws:/opt/aws ' +
' -u 0:0 '
reuseNode true
}
}
My script running in the container can 'ls /usr/local/docker/usr/bin" and see the aws command as an executable but the PATH isn't picking up the aws binary so I can't execute
eval $(/usr/local/docker/usr/bin/aws ecr get-login --no-include-email --region us-west-1)
jimroost
on 18 Apr 2018
The solution suggested by @mmiglier works for me using credentials into the pom.xml on the version 1.4.0
josmora
on 30 Jul 2018
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] picture](https://avatars.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 28 Sep 2018
1.4.10 is still failing to push to ecr, and the above workaround is not working anymore. Rolling back to 1.4.0 + docker-client 8.11.2
mmiglier
on 29 Mar 2019
Same problem with my configuration :
plugin version 1.4.10
docker-client:
Client:
Version: 18.09.7
API version: 1.39
Go version: go1.10.8
Git commit: 2d0083d
Built: Thu Jun 27 17:56:23 2019
OS/Arch: linux/amd64
Experimental: false
casper5822
on 8 Jul 2019
Related issues
bjornbak
·
5Comments
NZhuravlev
·
5Comments
destebanm
·
8Comments
zzsoszz
·
8Comments
blindenvy
·
3Comments
Most helpful comment
This is fixed in the docker-client library in newer versions. You can force the dependency in the plugin like this :
com.spotify
docker-client
shaded
8.10.0
```
...