Rolling updates in Docker - Step-by-Step Execution

Process Flow - Rolling updates

Start with current version running

↓

Deploy new version to some containers

↓

Check new version health

↓

Shift traffic

↓

Update remaining containers

↓

All containers running new version

↓

End

Rolling updates replace old containers with new ones gradually, checking health before continuing.

Execution Sample

Docker

docker service update --image myapp:v2 myapp_service
# Docker replaces containers one by one
# Checks health before moving on

This command updates a Docker service to a new image version using rolling updates.

Process Table

Step	Action	Containers Updated	Health Check	Result	Next Step
1	Start rolling update	0/3	N/A	Old version running	Update first container
2	Update container 1	1/3	Pass	Container 1 running v2	Update container 2
3	Update container 2	2/3	Pass	Container 2 running v2	Update container 3
4	Update container 3	3/3	Pass	All containers running v2	Complete update
5	Complete	3/3	N/A	Rolling update successful	End

💡 All containers updated and passed health checks, rolling update finished successfully.

Status Tracker

Variable	Start	After 1	After 2	After 3	Final
Containers Updated	0	1	2	3	3
Health Status	N/A	Pass	Pass	Pass	Pass
Version Running	v1	v2	v2	v2	v2

Key Moments - 2 Insights

Why does Docker update containers one by one instead of all at once?

Updating one container at a time ensures the service stays available and lets Docker check health before continuing, as shown in steps 2-4 of the execution table.

What happens if a container fails the health check during update?

If a container fails health check, Docker stops the update and can rollback or pause, preventing broken service. This is implied in the flow where 'Fail' leads to rollback or fix.

Visual Quiz - 3 Questions

Look at the execution table, how many containers are updated after step 3?

A 1

B 3

C 2

D 0

💡 Hint

Check the 'Containers Updated' column at step 3 in the execution table.

At which step does the rolling update complete successfully?

A Step 4

B Step 5

C Step 3

D Step 2

💡 Hint

Look for the row where 'Result' says 'Rolling update successful' in the execution table.

If the health check fails at step 2, what would happen next?

A Rollback or fix the issue

B Continue updating next containers

C Ignore and finish update

D Update all containers at once

💡 Hint

Refer to the concept flow where a failed health check leads to rollback or fix.

Concept Snapshot

Rolling updates replace old containers gradually.
Docker updates one container at a time.
Health checks after each update ensure stability.
If health fails, update pauses or rolls back.
This keeps service available during updates.

Full Transcript

Rolling updates in Docker mean updating containers one by one to a new version. First, the current version runs. Then Docker updates one container and checks if it is healthy. If it passes, Docker moves to the next container. This continues until all containers run the new version. If any container fails health check, Docker stops and can rollback. This process keeps the service running without downtime.

Practice

1. What is the main purpose of a rolling update in Docker?

easy

A. To restart the Docker daemon automatically

B. To delete all containers and recreate them at once

C. To backup container data before updating

D. To update containers gradually without downtime

Solution

1. Step 1: Understand rolling update concept

   A rolling update means updating parts of a system bit by bit instead of all at once.

2. Step 2: Apply to Docker containers

   In Docker, rolling updates replace containers one by one to avoid downtime.

3. Final Answer:

   To update containers gradually without downtime -> Option D

4. Quick Check:

   Rolling update = gradual update without downtime [OK]

Hint: Rolling update means gradual replacement, not all at once [OK]

Common Mistakes:

• Thinking rolling update deletes all containers simultaneously
• Confusing rolling update with backup process
• Assuming rolling update restarts Docker daemon

2. Which Docker command option is used to perform a rolling update on a service?

easy

A. docker service update --rolling-update

B. docker service update --rollback

C. docker service update --update-parallelism

D. docker service update --force

Solution

1. Step 1: Identify rolling update options

   Docker uses --update-parallelism to control how many containers update at once.

2. Step 2: Match option to rolling update

   This option allows gradual updates, which is the essence of rolling updates.

3. Final Answer:

   docker service update --update-parallelism -> Option C

4. Quick Check:

   Rolling update option = --update-parallelism [OK]

Hint: Use --update-parallelism to control rolling update speed [OK]

Common Mistakes:

• Using --force which restarts all containers immediately
• Assuming --rollback triggers rolling update
• Inventing a non-existent --rolling-update flag

3. Given the command:

docker service update --image myapp:v2 --update-parallelism 2 myservice

What will happen during this update?

medium

A. All containers of myservice update at once to v2

B. Two containers update at a time to v2 until all are updated

C. Only two containers update and the rest stay on old version

D. The service rolls back to the previous version

Solution

1. Step 1: Understand --update-parallelism effect

   The option --update-parallelism 2 means update 2 containers at once.

2. Step 2: Apply to service update

   Docker updates 2 containers to image v2, then moves to next 2, until all are updated.

3. Final Answer:

   Two containers update at a time to v2 until all are updated -> Option B

4. Quick Check:

   --update-parallelism 2 means update 2 containers at once [OK]

Hint: Parallelism number controls how many containers update simultaneously [OK]

Common Mistakes:

• Thinking all containers update simultaneously
• Believing only two containers update permanently
• Confusing update with rollback

4. You run:

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?

medium

A. The image myapp:v3 does not exist or is invalid

B. The update-delay is too short causing timeout

C. The update-parallelism value must be 1

D. Docker service update does not support update-delay

Solution

1. Step 1: Check update-delay and parallelism validity

   Both --update-delay and --update-parallelism are valid options and can be used together.

2. Step 2: Consider image availability

   If the new image myapp:v3 is missing or invalid, update fails and some containers remain old.

3. Final Answer:

   The image myapp:v3 does not exist or is invalid -> Option A

4. Quick Check:

   Update fails if new image is missing or bad [OK]

Hint: Check image existence if update leaves old containers [OK]

Common Mistakes:

• Assuming update-delay causes failure
• Thinking parallelism must be 1
• Believing update-delay is unsupported

5. You want to update a Docker service with 10 replicas using rolling updates. You want to update 3 containers at a time and wait 5 seconds between batches. Which command correctly achieves this?

hard

A. docker service update --image myapp:v2 --update-parallelism 3 --update-delay 5s myservice

B. docker service update --image myapp:v2 --update-parallelism 5 --update-delay 3s myservice

C. docker service update --image myapp:v2 --update-parallelism 10 --update-delay 0s myservice

D. docker service update --image myapp:v2 --update-delay 5s myservice

Solution

1. Step 1: Match update-parallelism to batch size

   To update 3 containers at a time, use --update-parallelism 3.

2. Step 2: Set delay between batches

   To wait 5 seconds between batches, use --update-delay 5s.

3. Step 3: Verify full command

   Combining these with the image and service name gives the correct command.

4. Final Answer:

   docker service update --image myapp:v2 --update-parallelism 3 --update-delay 5s myservice -> Option A

5. Quick Check:

   Parallelism 3 + delay 5s = correct rolling update command [OK]

Hint: Use --update-parallelism for batch size and --update-delay for wait time [OK]

Common Mistakes:

• Using wrong parallelism number
• Omitting update-parallelism option
• Setting delay but not parallelism