moby: Unable to update Swarm service with image from local library

@szantopeter @saamalik Let me know if I understand your issue correctly:

• The image your service is using is a local image
• You update the image by building it locally (while keeping the same tag)
• Then you try to do docker service update --image, and you find that the service isn’t updating

If the above is right, then this is expected based on the current design. Mainly because the service is pinned to digest only by looking at the registry, not the local image id. So if the image isn’t found in the registry, the Image field in the service spec will change from echo-service to echo-service, which is not enough to trigger a change. If you instead pushed the image to a registry each time you built your image, then you’ll notice that the Image field in the spec also has a digest, such as echo-service:latest@sha256:45jh34jk.... Updating the image will change the digest (the sha256 part and automatically trigger an update.

As @aaronlehmann has mentioned above, image IDs aren’t taken into account while deciding whether to update the image. We may consider it in the future, but it isn’t the case right now. Also, since you were using stack files, it is likely that the tag was being added at some point to trigger a change. For now, if --force works for you, then that’s what you should do. Alternatively, it is also possible to use just the full image ID to create the service. On updating, your ID should change, and an update will be triggered.

To confirm all this, look at the service spec by doing docker service inspect example_echo-service before and after your update, and you’ll see that the Image field looks the same.

@aaronlehmann this was the behavior pre 17.0.3.0 – now maybe that was a “bug” but I considered it a feature =)

Our devs tests the entire stack by running Docker for Mac with Swarm on their laptops. As each feature gets developed, they’ll run their local build script which will generate local docker images tagged :latest, after which they’ll deploy using the docker stack deploy -c ... stack command. In lieu of being able to just run docker stack deploy -c ... stack again for updates, previously they were running docker service update --image <component>:latest component for all components; and only the components which were updated got refreshed. Now the workflow has changed to call docker service update --force <component> which blindly refreshes the containers. Not a big deal, but ideally docker stack deploy (for updating) should play nice with local library as it does with private/public registry. My $0.02, cheers.

@nishanttotla I am also experiencing this issue. The scenario I am trying is to have a local docker image being built with the :latest tag. I have no repository where I put the images, I only have the local images. I alter the content slightly and re-build the image (again with the :latest tag). When I then run ‘docker stack deploy’ again, I get:

$ docker stack deploy -c docker-stack.yml foo
Updating service foo_cow (id: a6jamiub3cm3wxbg73vvkyupz)
image cow:latest could not be accessed on a registry to record
its digest. Each node will access cow:latest independently,
possibly leading to different nodes running different
versions of the image

Now, having read multiple issues all I have seen is a mix of “this is by design” and “use docker service update” (with image and force params). But still several issues seem open, such as #31357

The problem I have with this is that I just recently (last week) went through a large chunk of the Docker tutorials and I saw no mention of that this is intended. The documentation on the contrary suggests that having this workflow should re-deploy the changed service (since the image changed). I never used docker-compose, but I am getting the feeling from reading lots of resources that docker-compose actually does re-deploy in this case? But that is just a guess. If it does, the documentation is then even more confusing since there is an inconsistency between the two.

docker service update --image echo-service:latest prior to the new docker community 17.03.0 used to only update the container if the image-id changed.

Since this is a local image that’s not available from a registry, this doesn’t sound right. The tasks (containers) behind the service would only be updated if Docker is able to find out from a registry that the image at this tag has changed. Local images are never taken into consideration when deciding whether or not to update tasks.