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
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.
- 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).
I would like zero-downtime deployments. From my mind, that means:
- A single version of the application container is running
- A new update is published to the repo
- Gitlab assembles the Docker image
- Gitlab tells Docker Swarm to deploy a new version of the application
- Docker Swarm brings up the new container and connects it to the existing Docker Service
- Traefik should automatically choose the newest container to send requests to
- Docker Swarm then kills the old container
Thanks for your help!