Rolling updates

docker service update replaces a service's tasks batch by batch, following deploy.update_config: how many at a time, in which order, how long to watch each one. Done right, customers never notice a release.

How it works

parallelism (1 by default) sets the batch size, delay the pause between batches, monitor (5 s) how long each new task is watched. order: stop-first (default) stops the old task before starting the new one; start-first starts the new one beside it and stops the old one only when the new one is Running, which with a healthcheck means healthy. start_period gives a slow starter time before failed checks count.

What breaks

Without a healthcheck, new tasks receive traffic while they warm up. With a healthcheck but no start_period, a slow app is declared unhealthy and killed again and again, and the update pauses. A large parallelism replaces every replica at once.

In compose.yaml

services:
  api:
    image: registry.shop.internal/shop/api:1.5.0
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
      interval: 5s
      start_period: 60s
    deploy:
      replicas: 2
      update_config:
        parallelism: 1
        order: start-first
        monitor: 10s

See it break, then fix it

Write the Dockerfile or the compose file, type the docker commands, and watch a simulated server run them through reboots, upgrades and traffic. Free to start.

Open the learning path Open the sandbox