Skip to content
This repository has been archived by the owner on Mar 21, 2022. It is now read-only.

Authentication doenst work while pulling #140

Closed
hotstepper13 opened this issue Sep 23, 2015 · 5 comments
Closed

Authentication doenst work while pulling #140

hotstepper13 opened this issue Sep 23, 2015 · 5 comments

Comments

@hotstepper13
Copy link

We have the same Problem as menitoned by #104 (comment)

I allready created an issue within the docker-client but in the meantime i am note sure if it located in the client or the plugin.

Therefore here the stuff again:

we have setup artifactory as private registry and are able to push images to the registry by using the spotify maven plugin. Yesterday we discovered that if I clean the local cache our builds are no longer succeeding. After doing some research it looks like that the client isnt authenticating while pulling images from the remote registry.

In our logs I saw 3 requests to /v2/ which are answered with http status 401
After that I saw another 2 requests which seems to guess the artifact location.

While pushing I see one request to /v2/ and the 401 response. After that the client will authenticate and everything works well.

If I use plain docker everything is working as exspected.

We set up authentication by having a server with ID "artifactory" in our settings.xml and reference this by having the corrosponding entry.

        <plugin>
            <groupId>com.spotify</groupId>
            <artifactId>docker-maven-plugin</artifactId>
            <version>0.3.3</version>
            <configuration>
                <serverId>artifactory</serverId>
                <registryUrl>https://xxxxxxxxxxxxxxxxxxxxxxxx/v2/</registryUrl>
                <imageName>${docker.image.prefix}/${project.artifactId}</imageName>
                <dockerDirectory>src/main/docker</dockerDirectory>
                <resources>
                    <resource>
                        <targetPath>/</targetPath>
                        <directory>${project.build.directory}</directory>
                        <include>${project.build.finalName}.jar</include>
                    </resource>
                </resources>
            </configuration>
        </plugin>

I tried the latest tagged version of the spotify-docker-plugin which uses the latest tagged version of the docker-client.

Can someone verify if this is a bug in the library or a misuse? (In case of misuse any hint what we are doing wrong would be appreciatiated).

Thanks in advance and best regards

Frank

@brianshowers
Copy link

I'm seeing the same behavior. If the image that I'm trying to build is 1) based from an image in a private repo and 2) that base image is not in the local cache then the docker:build command fails with an authentication issue.

My auth data is stored in my .m2/settings.xml config. What's interesting is that I can docker:push images that I build just fine, so the auth is working with some goals. It just appears to not be working when I need to pull a base image to build.

The configuration from my pom.xml

<plugin>
    <groupId>com.spotify</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>0.3.3</version>
    <configuration>
        <serverId>containers.my.repo</serverId>
        <registryUrl>containers.my.repo</registryUrl>
        <baseImage>containers.my.repo/archetype/jdk-oracle:8.0</baseImage>
        <imageName>containers.my.repo/archetype/java-springboot:${project.version}</imageName>

        <resources>
            <resource>
                <targetPath>/</targetPath>
                <directory>${project.build.directory}</directory>
                <include>${project.build.finalName}.jar</include>
            </resource>
        </resources>
        <entryPoint>["java", "-jar", "/${project.build.finalName}.jar"]</entryPoint>
        <exposes>
            <expose>8080</expose>
        </exposes>
    </configuration>
</plugin>

Here's the log from the error that I receive

$mvn docker:build
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building springboot 1.7-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- docker-maven-plugin:0.3.3:build (default-cli) @ springboot ---
[INFO] Copying /user/working/target/springboot-1.7-SNAPSHOT.jar -> /user/working/target/docker/springboot-1.7-SNAPSHOT.jar
[INFO] Building image containers.my.repo/archetype/java-springboot:1.7-SNAPSHOT
Step 0 : FROM containers.my.repo/archetype/jdk-oracle:8.0
Pulling repository containers.my.repo/archetype/jdk-oracle
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.713 s
[INFO] Finished at: 2015-09-30T13:57:33+00:00
[INFO] Final Memory: 15M/37M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.3.3:build (default-cli) on project springboot: Exception caught: Error: Status 403 trying to pull repository archetype/jdk-oracle: "{\"error\": \"Permission Denied\"}" -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

If I manually docker pull containers.my.repo/archetype/jdk-oracle:8.0 first, then everything works fine. However, if I specify pullOnBuild=true to force a pull, it will start failing again.

@jerrykwchan
Copy link

I have similar issue (issue 142). As brianshowers said, if I pull the base image to docker host before build, the build goes through and push is succeeded. I add a dummy query before the docker image build task (see my pom.xml below) and the subsequence base image pull in docker image build goes through
pom

I found that if I enable basic authentication in the reverse proxy in front of the private registry, pulling the base image failed with the following error:
[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.3.4:build (default) on project sigmaadminui: Exception caught: Authentication is required. -> [Help 1]

If I skip authentication for GET/HEAD request in reverse proxy, the pulling of base image succeeded but it failed with the same error when pushing the image.

@s17t
Copy link

s17t commented Feb 12, 2016

I stumble upon this issue too. The OS is Debian 8.3, maven 3.3.3, docker client is 1.9.1. I use 0.4.0 version of the plugin. The POM plugins configuration is similar to:

<plugin>
    <groupId>com.spotify</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>${docker.maven.plugin.version}</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>build</goal>
            </goals>
        </execution>
    </executions>
<configuration>
    <serverId>privateRegistryId</serverId>
    <imageName>registry.private.it/blabla</imageName>
    <dockerDirectory>${project.basedir}/src/main/docker</dockerDirectory>
    <imageTags>
    <imageTag>${maven.build.timestamp}</imageTag>
    </imageTags>
    <resources>
    <resource>
        <targetPath>/</targetPath>
        <directory>${project.parent.basedir}/blabla/target/</directory>
        <includes>
            <include>blablabla.jar</include>
        </includes>
    </resource>
    <resource>
        <targetPath>/</targetPath>
        <directory>${project.parent.basedir}/blabla/target/</directory>
        <includes>
            <include>blabla.war</include>
        </includes>
    </resource>
    </resources>
</configuration>
</plugin>

The Dockerfile define a FROM from public registry but the plugin is unable to pull from it because:

Exception caught: Authentication is required.

@s17t
Copy link

s17t commented Oct 28, 2016

Any chance to see this issue fixed ? It makes impossible to automate build/push image from a mixed private/public repositories environment.

@mattnworb
Copy link
Member

I am not sure if this is still an issue, since the reports are pretty old, but #339 fixes all of the root causes

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants