39

I am using docker swarm and would like to deploy a service with docker-compose. My service uses a custom image called myuser/myrepo:mytag that I successfully deploy to Docker-Hub to a private repository.

My docker-compose looks like this:

version: "3.3"

services:

  myservice:
    image: myuser/myrepo:mytag
    ports:
      - "8080:8080"

Before executing, I successfully pulled the image with: docker pull myuser/myrepo:mytag

When I run docker stack deploy -c docker-compose.yml myapp I always receive the error: "No such image: myuser/myrepo:mytag".

Interestingly, running the same file using only: docker-compose up (i.e. without swarm mode) everything works fine and the service starts up.

I really don't understand why this is failing? I've already tried cleaning up docker with docker system prune and then repull my image, no success.

ice_chrysler
  • 2,633
  • 1
  • 21
  • 27

7 Answers7

58

Already found the solution. My image is hosted on a private repository. Besides the swarm manager (where I executed the commands), I had a running swarm worker.

When I ran docker stack deploy -c docker-compose.yml myapp docker deployed the service to the worker node (not the manager node as I thought). At the worker node, docker had no credentials to pull the image from the private repository. Hence, to fix this either pass the flag --with-registry-auth (which pushes the credentials for the repository to the worker node) or make sure that the service is deployed to a node where the image is present.

See: https://docs.docker.com/engine/reference/commandline/deploy/

ice_chrysler
  • 2,633
  • 1
  • 21
  • 27
  • 4
    Hi, I use `docker stack deploy --prune --with-registry-auth --resolve-image=always --compose-file docker-compose.yml stack_name` and I often get this error. It's very random, sometimes all nodes get the image, sometimes not. It's been driving me crazy for a while. Do you have any idea what the problem could be by any chance? I'm also using a private registry. – Konrad Feb 04 '21 at 14:22
  • @Konrad - just to chime in .. same here! after a fresh github workflow tagging, pushing, pulling and deploy to swarm the first run fails with the same error. no idea why – setcookie May 08 '23 at 09:46
6

I want to add another scenario that leads to the same outcome (error message) so that people won't bang their heads against the wall.

Another possibility is that you are trying to deploy the image with the insecure registry but forget to edit daemon.json on the server pulling the image.

If that is the case, lets this answer act as a reminder; and save you some time.

Curious Sam
  • 884
  • 10
  • 12
0

I had similar issue on mac when behind the corporate firewall.

I was able to resolve only after connecting directly to internet.

Just to update, while I am on VPN, I am able to access the internet without any proxy settings, and am able to download (docker) images just fine with docker run. Issue is only with docker-compose.

I did try changing the nameserver to 8.8.8.8 in resolv.conf in my VMs, but issue was not resolved.

ghitesh
  • 160
  • 2
  • 14
0

For me I struggled with an image I had deployed to a new registry I configured in my swarm. I was updating the stack using Portainer.

I configured all the necessary certificates and logins on all the nodes and verified I had uploaded the image using the following commands:

curl -X GET https://myregistry:5000/v2/_catalog curl -X GET https://myregistry:5000/v2/{image}/tags/list

No matter what I tried I always had the "No such image" error displayed on the service instances.

In a last ditch attempt I created a service (without the compose file) using exactly the same URL for my image as I had previously and it worked, i.e. docker found the image and started the service! Further attempts using the compose file then worked properly for this and all other new images.

Weird.

wintel-warrior
  • 131
  • 2
  • 6
0

Another problem that can cause exactly the same error in the case of using a private register running on the node manager of the swarm. Make sure you run the register as a SERVICE and not just as a container! May this save you time!

padu
  • 689
  • 4
  • 10
0

For me the problem was in gitlab authorization token ($CI_REGISTRY_USER, $CI_REGISTRY_PASSWORD), which is valid while deploing to master, but is not valid for workers as gitlab job is over.

Alexander Abramov
  • 1
  • 1
0

Another thing to be aware of: Disk space on the swarm node. Mine had run out of disk space and was producing this as an opaque error.

Gazza
  • 3,051
  • 1
  • 20
  • 22