How does "order: start-first" exactly work with "update_config"?

Docker Engine Swarm
1

Hi there,

I was wondering if there was more information on how order: start-first works:

app:
    image: myrepo/alpha-app
    deploy:
      replicas: 1
      update_config:
        parallelism: 1
        delay: 5s
        order: start-first

What the docs say

order: Order of operations during updates. One of stop-first (old task is stopped before starting new one), or start-first (new task is started first, and the running tasks briefly overlap.

Question:

  • If I have replicas: 1, does that mean it does NOT start a second container first because it is limited by the number of replicas?

Reason of “1 replica”:
I only really need one replica in this case because the app is running on a single host. I would like to keep the memory usage as low as possible, but still have zero-downtime deployments (if possible).

My goal

I would like zero-downtime deployments. From my mind, that means:

  1. A single version of the application container is running
  2. A new update is published to the repo
  3. Gitlab assembles the Docker image
  4. Gitlab tells Docker Swarm to deploy a new version of the application
  5. Docker Swarm brings up the new container and connects it to the existing Docker Service
  6. Traefik should automatically choose the newest container to send requests to
  7. Docker Swarm then kills the old container

Thanks for your help!

1 Like