<p>You don't need a restart policy with swarm mode. Swarm mode will constantly try to reconcile any differences between the current and target state. I've seen cases where the restart policy enforced by the docker engine, and the implicit reconciliation in swarm mode have conflicted and resulted in issues. The restart policy would also restart the stopped container which would implicitly break the goal to use a new image since the image can not change for the life of a container. Swarm mode, conversely, will recreate any stopped containers with a new container.</p>

<p>To have swarm use the current value of a tag, rather than resolving that tag to an image digest on the initial deploy, you need <code>docker stack deploy --resolve-image ...</code>. Note that I haven't tested if this will pull new images, I've only needed to use the feature to use locally built images that shouldn't be pulled from a registry. If Swarm mode doesn't pull new images, you'll also want an extra process to pull your image periodically.</p>

CC BY-SA 4.0
2020-04-06T13:28:13.420Z
`--resolve-image` does pull the latest version - but only when doing `docker stack deploy` or `docker service update`; it doesn't do it when the system reboots.

After wasting too much time on this, I actually just gave up, disabling the `restart_policy` and writing a systemd service to manage lifetime instead - this works great, as it calls `docker stack rm` and then docker stack deploy`. Annoying it wouldn't work with Swarm along tho
Cocowalla
CC BY-SA 4.0
2020-04-06T13:35:05.953Z
There's no need to do a `stack rm` when you are doing a `stack deploy`, the deploy will update for all the differences. The `--resolve-image` prevents the image digest resolution, turning `latest` into `sha256:a12341...`. But if an old `latest` is already pulled locally, sounds like it won't update that and you'd need to run a `pull` again.
BMitch
CC BY-SA 4.0
2020-04-06T09:59:42.703Z
2020-04-06T09:59:42.703Z
BMitch
<p>This is one approach to keeping swarm upto date, only runs after startup, but does continuously monitor based on period schedule in minutes.</p>
<p><a href="https://github.com/djmaze/shepherd" rel="nofollow noreferrer">https://github.com/djmaze/shepherd</a></p>

CC BY-SA 4.0
2022-05-06T22:49:15.490Z
2022-05-06T22:49:15.490Z
Alex Balcanquall
<p>I'm using Docker Swarm, and I have <code>condition: always</code> in the <code>restart_policy</code> of my compose file, so my services are started automatically when the system reboots or the Docker daemon is restarted.</p>

<p>What I'm trying to achieve is to also have the services pull and run the <em>latest</em> image when the system reboots or the daemon is restarted. This is for an IoT device, so yes, I really do want to do this.</p>

<p>Now, if I manually take down and restart the stack, or if I use <code>docker service update --force --image my-image:latest my-service</code>, then the latest image is pulled and ran. But if I restart the system, it just keeps running the old image, and doesn't pull the latest one.</p>

<p>I could work around this by removing the restart policy and using systemd to manage lifecycle instead, but I really don't want that extra hassle or complexity, and I'm not even sure how to work that to restart services that crash.</p>

<p>Is there some way to achieve this with Docker Swarm alone?</p>

<docker><docker-compose><docker-swarm><systemd>
How to automatically update Swarm services when the Docker daemon restarts
Cocowalla
# How to automatically update Swarm services when the Docker daemon restarts

(Asked by: username_0 on 2020-03-24)

I'm using Docker Swarm, and I have `condition: always` in the `restart_policy` of my compose file, so my services are started automatically when the system reboots or the Docker daemon is restarted.

What I'm trying to achieve is to also have the services pull and run the *latest* image when the system reboots or the daemon is restarted. This is for an IoT device, so yes, I really do want to do this.

Now, if I manually take down and restart the stack, or if I use `docker service update --force --image my-image:latest my-service`, then the latest image is pulled and ran. But if I restart the system, it just keeps running the old image, and doesn't pull the latest one.

I could work around this by removing the restart policy and using systemd to manage lifecycle instead, but I really don't want that extra hassle or complexity, and I'm not even sure how to work that to restart services that crash.

Is there some way to achieve this with Docker Swarm alone?

**Tags:** docker, docker-compose, docker-swarm, systemd


---

## 2 answers

### Answer by username_1 on 2020-04-06. Score: 2

You don't need a restart policy with swarm mode. Swarm mode will constantly try to reconcile any differences between the current and target state. I've seen cases where the restart policy enforced by the docker engine, and the implicit reconciliation in swarm mode have conflicted and resulted in issues. The restart policy would also restart the stopped container which would implicitly break the goal to use a new image since the image can not change for the life of a container. Swarm mode, conversely, will recreate any stopped containers with a new container.

To have swarm use the current value of a tag, rather than resolving that tag to an image digest on the initial deploy, you need `docker stack deploy --resolve-image ...`. Note that I haven't tested if this will pull new images, I've only needed to use the feature to use locally built images that shouldn't be pulled from a registry. If Swarm mode doesn't pull new images, you'll also want an extra process to pull your image periodically.

> **Comments:**
> **username_0**: `--resolve-image` does pull the latest version - but only when doing `docker stack deploy` or `docker service update`; it doesn't do it when the system reboots.  After wasting too much time on this, I actually just gave up, disabling the `restart_policy` and writing a systemd service to manage lifetime instead - this works great, as it calls `docker stack rm` and then docker stack deploy`. Annoying it wouldn't work with Swarm along tho  
> **username_1**: There's no need to do a `stack rm` when you are doing a `stack deploy`, the deploy will update for all the differences. The `--resolve-image` prevents the image digest resolution, turning `latest` into `sha256:a12341...`. But if an old `latest` is already pulled locally, sounds like it won't update that and you'd need to run a `pull` again.  

---

### Answer by username_2 on 2022-05-06. Score: 0

This is one approach to keeping swarm upto date, only runs after startup, but does continuously monitor based on period schedule in minutes.

<https://github.com/djmaze/shepherd>


---

