Unable to push image to private registry (no basic auth credentials)

Drone Support
1

Hello,

I’ve been losing my hair trying to push a built docker image to my private registry.
I’m running drone 1.1 (server + agent), from the official docker images.

I feel like I tried everything from the official docs, to what can be found here : http://discuss.harness.io/t/how-to-pull-private-images-with-1-0/3155 without success.

My pipeline definition now looks like that :

kind: pipeline
name: default
steps:

  • name: hello
    image: alpine
    commands:
    - echo “stupid step”
    - echo “latest” > .tags
  • name: docker
    image: plugins/docker
    settings:
    repo: registry.xxx.yyy/test/pipeline_poc

Build output :

[ … ]
Successfully built 632950c970c7
104 Successfully tagged d681ed873716f896fa80a8adf00ae02b3b76f381:latest
105 + /usr/local/bin/docker tag d681ed873716f896fa80a8adf00ae02b3b76f381 registry.xxx.yyy/test/pipeline_poc:latest
106 + /usr/local/bin/docker push registry.xxx.yyy/test/pipeline_poc:latest
107 The push refers to repository [registry.xxx.yyy/test/pipeline_poc]
108 cc5065ac7678: Preparing
109 a464c54f93a9: Preparing
110 no basic auth credentials
time=“2019-05-02T15:31:41Z” level=fatal msg=“exit status 1”

The running agent have the following environment variables :

$ sudo docker inspect drone-agent | grep DRONE
“DRONE_DOCKER_CONFIG=/root/.docker/config.json”,
“DRONE_RPC_SECRET=redacted”,
“DRONE_RPC_SERVER=https://cd.xxx.yyy”,
“DRONE_RUNNER_OS=linux”,
“DRONE_RUNNER_ARCH=amd64”,
“DRONE_RUNNER_PLATFORM=linux/amd64”,
“DRONE_RUNNER_CAPACITY=1”

The /root/.docker/config.json (on the host) contains the following :

{
“auths”: {
“registry.xxx.yyy”: {
“auth”: “mysuperauthstring”
}
}
}

And is mounted in the agent container on the same path (/root/.docker/config.json).

Sorry if I missed something, but honestly I’m stucked :frowning:

Thanks !

2

the config.json file is used to pull private images defined in your yaml, for example:

steps:
- name: build
  image: registry.company.com/hello-world

the config.json credentials are never exposed to your pipeline, and are therefore not exposed to any plugins, including the docker plugin. Plugins are completely independent entities. If you want to pass sensitive data to plugins such as credentials, you need to use secrets.

you can manage secrets in the repository settings screen in drone, and then reference them in your plugin configuration. There is an example in the plugin documentation at http://plugins.drone.io/drone-plugins/drone-docker/

3

Thanks for your swift reply.

Unfortunately, passing secrets/config was the first thing I tried (but tried again just to be sure), this time I get the following :

/usr/local/bin/dockerd --data-root /var/lib/docker
2 time=“2019-05-02T20:09:44Z” level=fatal msg=“Error authenticating: exit status 1”

Without not much more details …
And the pipeline looks like that (I know, hardcoding creds in the yml is bad) :wink:

  • name: docker
    image: plugins/docker
    settings:
    repo: registry.xxx.yyy/test/pipeline_poc
    username: myuser
    password: mypassword
    registry: registry.xxx.yyy

PS : also tried adding debug: true & launch_debug: true as stated in the documentation but didn’t get more information

:frowning:

4

Error authenticating: exit status 1 could indicate the credentials passed to drone are incorrect. It could also indicate a networking issue from inside the container not being able to reach the registry server. Also note that providing the full logs can sometimes help us debug.

Unfortunately Docker does not tell us why login failed, to my knowledge. So there is no way to get more detailed information from Docker. You could check your registry server to see if there is anything in the logs that might be helpful.

1 Like
5

It was the only log I got :slight_smile:

AFAIK there’s no reason that would prevent the container to reach the registry but I’ll try to get deeper in this direction.

Will update the post if I find something useful, anyway, thanks for your help !

6

the following should yield more logs:

settings:
  debug: true

the only other possible root cause I am aware of, which is very uncommon, is the inability to start docker (docker-in-docker) inside the plugin container. This happens sometimes if the host machine docker daemon is using the devicemapper storage driver or has some special security policy that prevents --privileged containers. But again, this is very uncommon.

1 Like
7

PEBKAC : you were right, since the beginning looks like I was using a wrong user/password combination :frowning:

Sorry for the noise.