Moby: Error message on service create with an image hosted in a private repository

Created on 30 Mar 2017  ·  3Comments  ·  Source: moby/moby

Description

I'm getting an error whenever I create a service in swarm cluster with an image that hosted in a private repository on docker hub.
The service is working, it's just the error message that is printed every time I create a service.

Steps to reproduce the issue:

  1. Create a private repository in docker hub
  2. Create a swarm cluster
  3. Login to docker
  4. Pull the image on the server
  5. Create a service with the image

Describe the results you received:

unable to pin image organization/some-image to digest: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

Describe the results you expected:
No error message

Output of docker version:

Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 3
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 33
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: active
 NodeID: omkzmqvpztv77kkg4j7w6dhj9
 Is Manager: true
 ClusterID: zpzn4xvqs6h5drt29423a7wr6
 Managers: 1
 Nodes: 2
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: x.x.x.x
 Manager Addresses:
  x.x.x.x:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-70-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.66 GiB
Name: name
ID: CMZP:AJOT:ELIE:T4NT:52JS:A6U6:LYE4:DNPW:LCJB:R2UR:XO3K:CDP6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: intezerdev
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 size=f8
 provider=azure
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
azure, using docker-machine

areswarm kinquestion statumore-info-needed versio17.03

Most helpful comment

This is expected; when creating a service, docker does not automatically pass on your credentials. Passing credentials / authentication information is an explicit action (by design), as those credentials will be stored in the swarm, and are distributed to the nodes where the service is deployed on.

To pass credentials, use the --with-registry-auth option when creating the service, or to _update_ the authentication information on an existing service (docker service update --with-registry-auth).

I don't think there's a bug here, but let me know if that worked, or if you're still running into issues

All 3 comments

This is expected; when creating a service, docker does not automatically pass on your credentials. Passing credentials / authentication information is an explicit action (by design), as those credentials will be stored in the swarm, and are distributed to the nodes where the service is deployed on.

To pass credentials, use the --with-registry-auth option when creating the service, or to _update_ the authentication information on an existing service (docker service update --with-registry-auth).

I don't think there's a bug here, but let me know if that worked, or if you're still running into issues

w.r.t. Pull the image on the server, then deploy; Swarm mode "pins" images to their digest, so guarantee that all instances of your service run _exactly_ the same version of your image. For this, it will contact the registry, and resolve the "digest" (immutable tag). For this, it needs access to the registry. If resolving the digest fails, docker will fall back to using the image:tag you provided when creating the service, and use a local image (if it exists); see https://github.com/docker/docker/issues/31518

I'll go ahead and close this issue, but feel free to continue the discussion if you need more information 👍

Was this page helpful?
0 / 5 - 0 ratings