What steps does docker swarm take when doing a rolling update with start-first?

Question

When docker swarm does a rolling update with stop-first on multiple running container instances, it takes -among others- the following steps in order for each container in a row:

1. Remove the container from its internal load balancer

2. Send a SIGTERM signal to the container.

3. With respect to the stop-grace-period, send a SIGKILL signal.

4. Start a new container

5. Add the new container to its internal load balancer

But which order of steps are taken when I want to do a rolling update with start-first?

Will the old- and new- container be available through the loadbalancer at the same time (until the old one has stopped and removed from the lb)?

Or will the new container first be started and not be added to the loadbalancer until the old container is stopped and removed from the loadbalancer?

The latter would nescesarry for processes that are bounded to a specific instance of a service (container).

Answer 1

But which order of steps are taken when I want to do a rolling update with start-first?

It's basically the reverse. New container starts, added to LB, then the old one is removed from LB and sent shutdown signal.

Will the old- and new- container be available through the loadbalancer at the same time (until the old one has stopped and removed from the lb)?

Yes.

A reminder that most of this will not be seamless (or near zero downtime) unless you (at a minimum) have healthchecks enabled in the service. I talk about this a little in this YouTube video.