Rolling updates in Docker - Commands & Configuration

Introduction

When you update an application running in Docker containers, you want to avoid downtime. Rolling updates let you replace old containers with new ones gradually, so your app stays available during the update.

When you want to update your web app without stopping all users at once

When you need to fix bugs or add features to a running service without downtime

When you want to test new versions of your app on a few containers before full rollout

When you manage multiple replicas of a service and want smooth transitions

When you want to keep your app running while updating its Docker image

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  webapp:
    image: my-app:1.0
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
    ports:
      - "8080:80"

This file defines a service named webapp running 3 copies (replicas) of the app.

The update_config section controls the rolling update: it updates one container at a time (parallelism: 1) and waits 10 seconds between updates (delay: 10s).

This setup ensures smooth updates without downtime.

Commands

This command deploys the stack named 'myapp' using the docker-compose.yml file. It starts the service with 3 replicas as defined.

Terminal

docker stack deploy -c docker-compose.yml myapp

Expected Output

Creating network myapp_default

Creating service myapp_webapp

→

-c - Specifies the compose file to use for deployment

This command lists all running services in the Docker swarm to verify the service is up.

Terminal

docker service ls

Expected Output

ID                  NAME                MODE                REPLICAS            IMAGE               PORTS

abc123def456        myapp_webapp        replicated          3/3                 my-app:1.0          *:8080->80/tcp

This command updates the running service to use the new image version 1.1. Docker performs a rolling update based on the update_config settings.

Terminal

docker service update --image my-app:1.1 myapp_webapp

Expected Output

myapp_webapp

overall progress: 3 out of 3 tasks

1/3: running   [==================================================>]

2/3: running   [==================================================>]

3/3: running   [==================================================>]

verify: Service converged

→

--image - Specifies the new image to update the service with

This command shows the status of each task (container) in the service to confirm the update completed successfully.

Terminal

docker service ps myapp_webapp

Expected Output

ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS

xyz789abc123        myapp_webapp.1      my-app:1.1          node1               Running             Running 2 minutes ago

uvw456def789        myapp_webapp.2      my-app:1.1          node2               Running             Running 2 minutes ago

rst123uvw456        myapp_webapp.3      my-app:1.1          node3               Running             Running 2 minutes ago

Key Concept

If you remember nothing else from this pattern, remember: rolling updates replace containers one by one to keep your app running without downtime.

Common Mistakes

Updating the service image without defining update_config in the compose file

Docker updates all containers at once by default, causing downtime.

Set update_config with parallelism and delay to control the rolling update speed.

Using docker run instead of docker stack deploy for multi-replica services

docker run manages single containers and cannot perform rolling updates on multiple replicas.

Use docker stack deploy with a compose file defining replicas and update_config.

Not verifying the update status with docker service ps

You might miss failed updates or containers stuck in error state.

Always check service tasks status after update to confirm success.

Summary

Define your service with multiple replicas and update_config in docker-compose.yml for rolling updates.

Deploy the stack with docker stack deploy to start the service.

Update the service image with docker service update to trigger a rolling update.

Check the update progress and status with docker service ls and docker service ps.

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