3

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).

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140

1 Answers1

3

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.

Bret Fisher
  • 8,164
  • 2
  • 31
  • 36
  • 1
    Thx Bret! Indeed we want zero downtime and have healthchecks in place. Unfortunately we've a service in our swarm that can not be scaled. This service can only run as a single instance. So for this one we can not use **start-first**. We could have more zero-downtime, if we could do: start new container, remove old container from LB, add new container to LB, send shutdown signal to the old container. – Johan Vogelzang Oct 08 '18 at 07:25
  • Yea that option doesn't exist. What's the real limitation? HTTP session state? – Bret Fisher Oct 08 '18 at 18:53