Rolling updates in Docker - Deep Dive

Overview - Rolling updates

What is it?

Rolling updates is a way to update software or services gradually without stopping everything at once. Instead of shutting down all old versions and starting new ones, it replaces them little by little. This keeps the service running smoothly and avoids downtime. In Docker, rolling updates help update containers safely.

Why it matters

Without rolling updates, updating software means stopping the whole service, causing downtime and unhappy users. Rolling updates solve this by updating parts step-by-step, so users barely notice changes. This keeps websites and apps available all the time, which is very important for businesses and users.

Where it fits

Before learning rolling updates, you should understand basic Docker concepts like containers, images, and services. After rolling updates, you can learn about advanced deployment strategies like blue-green deployments and canary releases to improve update safety even more.

Mental Model

Core Idea

Rolling updates replace old versions with new ones gradually to keep services running without interruption.

Think of it like...

Imagine changing the tires on a moving car one by one instead of stopping the car to change all tires at once. This way, the car keeps moving smoothly while the tires get replaced.

Service Update Process:

Old Version Containers  ──▶ Replace one container ──▶ New Version Container
│                          │                          │
│                          └─ Repeat step-by-step ────┘
│
│ Service stays available during update

Build-Up - 7 Steps

1

Foundation

Understanding Docker Services

Concept: Learn what Docker services are and how they run containers in a group.

Docker services let you run multiple containers together as one unit. This helps manage many containers easily. Each service can have many replicas (copies) running at the same time.

Result

You can start, stop, and manage groups of containers as a single service.

Knowing services is key because rolling updates work by changing these groups gradually.

2

Foundation

Basics of Docker Container Updates

Concept: Understand how containers are updated by replacing old ones with new versions.

When you update a container, Docker stops the old container and starts a new one with the updated image. Doing this all at once causes downtime because the service stops briefly.

Result

Updating containers without strategy causes service interruption.

Recognizing the problem of downtime motivates the need for rolling updates.

3

Intermediate

How Rolling Updates Work in Docker

🤔Before reading on: do you think Docker updates all containers at once or one by one during rolling updates? Commit to your answer.

Concept: Rolling updates replace containers one at a time to avoid downtime.

Docker updates services by stopping one old container and starting one new container at a time. This process repeats until all containers run the new version. The service stays available because some containers keep running old versions while others update.

Result

Service remains available with minimal interruption during updates.

Understanding the step-by-step replacement explains how downtime is avoided.

4

Intermediate

Configuring Rolling Update Parameters

🤔Before reading on: do you think you can control how many containers update at once or how long Docker waits between updates? Commit to your answer.

Concept: Docker allows setting how many containers update simultaneously and delay between updates.

You can set parameters like 'parallelism' (how many containers update at once) and 'delay' (wait time between updates) in Docker service update commands. This controls the speed and safety of the update.

Result

You can customize updates to balance speed and risk of downtime.

Knowing these controls helps tailor updates to your service needs and avoid overload.

5

Intermediate

Using Docker CLI for Rolling Updates

Concept: Learn the exact Docker commands to perform rolling updates on services.

Use 'docker service update' with options like '--image' to specify the new image, '--update-parallelism' to set how many containers update at once, and '--update-delay' to set wait time. Example: docker service update --image myapp:v2 --update-parallelism 1 --update-delay 10s myservice

Result

The service updates containers one by one every 10 seconds to the new image.

Knowing the commands lets you perform controlled rolling updates in real projects.

6

Advanced

Handling Failures During Rolling Updates

🤔Before reading on: do you think Docker automatically stops updates if a container fails during rolling update? Commit to your answer.

Concept: Docker can pause or rollback updates if problems occur during rolling updates.

Docker monitors container health during updates. If a new container fails to start or is unhealthy, Docker can pause the update or rollback to the previous version to keep the service stable. You can configure health checks to help Docker decide.

Result

Service stays stable by avoiding broken updates.

Understanding failure handling prevents service crashes during updates.

7

Expert

Optimizing Rolling Updates for Large Clusters

🤔Before reading on: do you think updating many containers slowly is always best, or can faster updates be safe with the right setup? Commit to your answer.

Concept: Balancing update speed and safety in large Docker clusters requires tuning parameters and monitoring.

In large clusters, updating too slowly wastes time, but too fast risks downtime. Experts tune 'parallelism' and 'delay' based on cluster size, resource limits, and monitoring feedback. They also combine rolling updates with load balancers and health checks for smooth transitions.

Result

Efficient updates that keep services stable and minimize downtime.

Knowing how to tune updates for scale is key for real-world production environments.

Under the Hood

Docker rolling updates work by the swarm manager orchestrating container replacements. It stops a set number of old containers, starts new ones with the updated image, and waits for them to become healthy before proceeding. This process repeats until all containers run the new version. Health checks and update parameters guide this flow to ensure stability.

Why designed this way?

Rolling updates were designed to solve the problem of downtime during updates. Instead of stopping all containers at once, gradual replacement keeps services available. This design balances update speed with reliability, allowing operators to control the process and recover from failures automatically.

┌───────────────┐       ┌───────────────────────┐       ┌───────────────┐
│ Old Containers│──────▶│ Replace 1 at a time    │──────▶│ New Containers│
│ (running v1)  │       │ (stop old, start new) │       │ (running v2)  │
└───────────────┘       └───────────────────────┘       └───────────────┘
         │                      │                          │
         │<---- Health checks and delays control ---->│

Myth Busters - 4 Common Misconceptions

Quick: Does Docker update all containers simultaneously during rolling updates? Commit yes or no.

Common Belief: Docker replaces all containers at once during updates.

Reality: Docker replaces containers one or a few at a time based on update settings.

Why it matters: Believing all update at once leads to expecting downtime and misconfiguring update parameters.

Quick: Can rolling updates guarantee zero downtime in all cases? Commit yes or no.

Common Belief: Rolling updates always guarantee zero downtime.

Reality: Rolling updates minimize downtime but cannot guarantee zero downtime if containers fail or health checks are misconfigured.

Why it matters: Overconfidence can cause unpreparedness for failures and service interruptions.

Quick: Does Docker automatically rollback updates on failure without any configuration? Commit yes or no.

Common Belief: Docker always rolls back updates automatically if something goes wrong.

Reality: Rollback requires proper health checks and update failure policies to be configured; otherwise, Docker may continue with broken updates.

Why it matters: Assuming automatic rollback can cause unnoticed broken services in production.

Quick: Is rolling update the only way to update Docker services safely? Commit yes or no.

Common Belief: Rolling updates are the only safe update method for Docker services.

Reality: Other methods like blue-green deployments or canary releases also provide safe update strategies.

Why it matters: Limiting to rolling updates prevents exploring better strategies for specific needs.

Expert Zone

1

Rolling update speed should be balanced with system load; updating too many containers at once can overload resources.

2

Health checks must be carefully designed to reflect real service readiness, or updates may proceed with unhealthy containers.

3

Combining rolling updates with load balancer draining improves user experience by avoiding traffic to containers being stopped.

When NOT to use

Avoid rolling updates when you need instant switchovers or when the new version is incompatible with the old one. In such cases, blue-green deployments or canary releases are better alternatives.

Production Patterns

In production, rolling updates are often combined with monitoring tools and alerting to detect issues early. Teams automate rollback triggers and use staged rollouts to subsets of users before full deployment.

Connections

Blue-Green Deployment

Alternative deployment strategy

Understanding rolling updates helps appreciate blue-green deployments as a method that switches traffic instantly between two environments instead of gradual replacement.

Load Balancing

Supports rolling updates by managing traffic

Load balancers direct user requests away from containers being updated, ensuring smooth user experience during rolling updates.

Biological Cell Regeneration

Natural gradual replacement process

Like rolling updates, biological systems replace cells gradually to maintain function without interruption, showing a natural parallel to software updates.

Common Pitfalls

#1 Updating all containers at once causing downtime.

Wrong approach:

docker service update --image myapp:v2 myservice

Correct approach:

docker service update --image myapp:v2 --update-parallelism 1 --update-delay 10s myservice

Root cause:

Not setting update parameters causes Docker to update all containers simultaneously by default.

#2 No health checks configured, leading to broken containers running.

Wrong approach:

docker service create --name myservice myapp:v1

Correct approach:

docker service create --name myservice --health-cmd 'curl -f http://localhost/ || exit 1' --health-interval 10s myapp:v1

Root cause:

Missing health checks means Docker cannot detect if new containers are healthy during updates.

#3 Assuming rollback happens automatically without configuration.

Wrong approach:

docker service update --image myapp:v2 myservice

Correct approach:

docker service update --image myapp:v2 --rollback myservice

Root cause:

Rollback must be explicitly triggered or configured; it is not automatic.

Key Takeaways

Rolling updates replace containers gradually to keep services running without downtime.

Docker allows controlling update speed and parallelism to balance safety and speed.

Health checks are essential to detect failures and keep updates safe.

Rolling updates are one of several deployment strategies; others may suit different needs.

Expert use involves tuning parameters, monitoring, and combining with load balancing for smooth production updates.

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