Rolling updates in Docker - Time & Space Complexity
When updating applications with Docker, rolling updates help avoid downtime by updating containers gradually.
We want to understand how the update time grows as the number of containers increases.
Analyze the time complexity of this rolling update command.
docker service update \
--image myapp:v2 \
--update-parallelism 2 \
--update-delay 10s \
myapp_service
This command updates the service containers two at a time, waiting 10 seconds between batches.
Look at what repeats during the update process.
- Primary operation: Updating a batch of containers in parallel.
- How many times: Number of batches equals total containers divided by batch size (parallelism).
As the number of containers grows, the update time grows in steps based on batch size and delay.
| Input Size (n) | Approx. Operations (batches) |
|---|---|
| 10 containers | 5 batches (2 containers each) |
| 100 containers | 50 batches |
| 1000 containers | 500 batches |
Pattern observation: The total update time grows roughly linearly with the number of containers.
Time Complexity: O(n)
This means the update time increases directly in proportion to the number of containers.
[X] Wrong: "Updating containers in parallel means update time stays the same no matter how many containers there are."
[OK] Correct: Even with parallel updates, batches happen one after another, so more containers mean more batches and more total time.
Understanding how rolling updates scale helps you design smooth deployments that keep apps running without interruption.
What if we increased the update parallelism from 2 to 5? How would the time complexity change?
Practice
rolling update in Docker?Solution
Step 1: Understand rolling update concept
A rolling update means updating parts of a system bit by bit instead of all at once.Step 2: Apply to Docker containers
In Docker, rolling updates replace containers one by one to avoid downtime.Final Answer:
To update containers gradually without downtime -> Option DQuick Check:
Rolling update = gradual update without downtime [OK]
- Thinking rolling update deletes all containers simultaneously
- Confusing rolling update with backup process
- Assuming rolling update restarts Docker daemon
Solution
Step 1: Identify rolling update options
Docker uses--update-parallelismto control how many containers update at once.Step 2: Match option to rolling update
This option allows gradual updates, which is the essence of rolling updates.Final Answer:
docker service update --update-parallelism -> Option CQuick Check:
Rolling update option = --update-parallelism [OK]
- Using --force which restarts all containers immediately
- Assuming --rollback triggers rolling update
- Inventing a non-existent --rolling-update flag
docker service update --image myapp:v2 --update-parallelism 2 myservice
What will happen during this update?
Solution
Step 1: Understand --update-parallelism effect
The option--update-parallelism 2means update 2 containers at once.Step 2: Apply to service update
Docker updates 2 containers to image v2, then moves to next 2, until all are updated.Final Answer:
Two containers update at a time to v2 until all are updated -> Option BQuick Check:
--update-parallelism 2 means update 2 containers at once [OK]
- Thinking all containers update simultaneously
- Believing only two containers update permanently
- Confusing update with rollback
docker service update --image myapp:v3 --update-parallelism 3 --update-delay 10s myservice
But the update fails and leaves some containers on old version. What is a likely cause?
Solution
Step 1: Check update-delay and parallelism validity
Both--update-delayand--update-parallelismare valid options and can be used together.Step 2: Consider image availability
If the new imagemyapp:v3is missing or invalid, update fails and some containers remain old.Final Answer:
The image myapp:v3 does not exist or is invalid -> Option AQuick Check:
Update fails if new image is missing or bad [OK]
- Assuming update-delay causes failure
- Thinking parallelism must be 1
- Believing update-delay is unsupported
Solution
Step 1: Match update-parallelism to batch size
To update 3 containers at a time, use--update-parallelism 3.Step 2: Set delay between batches
To wait 5 seconds between batches, use--update-delay 5s.Step 3: Verify full command
Combining these with the image and service name gives the correct command.Final Answer:
docker service update --image myapp:v2 --update-parallelism 3 --update-delay 5s myservice -> Option AQuick Check:
Parallelism 3 + delay 5s = correct rolling update command [OK]
- Using wrong parallelism number
- Omitting update-parallelism option
- Setting delay but not parallelism
Ready to prove it?
Pass the test and this pattern moves unknown
