Container orchestration in production in Docker - Step-by-Step Execution

Process Flow - Container orchestration in production

Define container images

↓

Create container specs

↓

Deploy to orchestration platform

↓

Platform schedules containers

↓

Monitor container health

↓

Scale containers up/down

↓

Handle failures & restart

↓

Update containers with zero downtime

This flow shows how container orchestration manages container deployment, scaling, health, and updates automatically in production.

Execution Sample

Docker

docker service create --name webapp --replicas 3 nginx

docker service ls

docker service ps webapp

docker service scale webapp=5

This code creates a service with 3 nginx containers, lists services, shows container tasks, then scales the service to 5 containers.

Process Table

Step	Command	Action	Result/Output
1	docker service create --name webapp --replicas 3 nginx	Create a service named 'webapp' with 3 nginx containers	Service 'webapp' created with 3 replicas
2	docker service ls	List all running services	ID NAME MODE REPLICAS IMAGE xyz webapp replicated 3/3 nginx:latest
3	docker service ps webapp	Show tasks (containers) for 'webapp'	ID NAME NODE DESIRED STATE CURRENT STATE abc webapp.1 node1 Running Running 2 minutes def webapp.2 node2 Running Running 2 minutes ghi webapp.3 node3 Running Running 2 minutes
4	docker service scale webapp=5	Scale 'webapp' service to 5 containers	webapp scaled to 5 replicas
5	docker service ls	List services after scaling	ID NAME MODE REPLICAS IMAGE xyz webapp replicated 5/5 nginx:latest
6	docker service ps webapp	Show updated tasks for 'webapp'	ID NAME NODE DESIRED STATE CURRENT STATE abc webapp.1 node1 Running Running 5 minutes def webapp.2 node2 Running Running 5 minutes ghi webapp.3 node3 Running Running 5 minutes jkl webapp.4 node1 Running Running 1 minute mno webapp.5 node2 Running Running 1 minute
7	docker service update --image nginx:1.21 webapp	Update service to new image version	Service 'webapp' updated to image nginx:1.21 with rolling update
8	docker service ps webapp	Show tasks during update	Some tasks restarting with new image, old tasks stopping
9	docker service ls	Final service state	ID NAME MODE REPLICAS IMAGE xyz webapp replicated 5/5 nginx:1.21
10	Exit	All containers running updated image, scaling and update complete	Orchestration successful

💡 All containers are running the updated image with desired replicas; orchestration tasks complete.

Status Tracker

Variable	Start	After Step 1	After Step 4	After Step 7	Final
replicas	0	3	5	5	5
image_version	none	nginx:latest	nginx:latest	nginx:1.21	nginx:1.21
service_status	none	created	scaled	updating	running updated

Key Moments - 3 Insights

Why does the number of replicas increase after the scale command?

Because the 'docker service scale' command changes the desired number of container replicas from 3 to 5, as shown in execution_table step 4 and 5.

How does the orchestration platform update containers without downtime?

It performs a rolling update by restarting containers one by one with the new image, keeping others running, as seen in steps 7 and 8.

What happens if a container fails during orchestration?

The platform automatically restarts the failed container to maintain the desired state, though this is implied in the flow and not shown explicitly in the table.

Visual Quiz - 3 Questions

Look at the execution table at step 4. What does the command do?

A Creates a new service with 5 replicas

B Scales the existing service to 5 replicas

C Deletes the service named webapp

D Updates the service image to nginx:1.21

💡 Hint

Check the 'Action' and 'Result/Output' columns at step 4 in the execution_table.

At which step does the service image version change?

A Step 1

B Step 4

C Step 7

D Step 9

💡 Hint

Look at the 'Command' and 'Result/Output' columns describing image update in the execution_table.

According to variable_tracker, what is the number of replicas after step 7?

A 5

B 0

C 3

D 7

💡 Hint

Check the 'replicas' row and the 'After Step 7' column in variable_tracker.

Concept Snapshot

Container orchestration manages multiple containers automatically.
Use commands like 'docker service create' to deploy.
Scale with 'docker service scale' to adjust replicas.
Update images with 'docker service update' for zero downtime.
Orchestration handles failures and keeps desired state.

Full Transcript

Container orchestration in production means managing many containers automatically. First, you create a service with a set number of container replicas. The orchestration platform schedules these containers on nodes. You can scale the number of containers up or down with a simple command. When updating the container image, the platform performs a rolling update to avoid downtime by restarting containers one at a time. It also monitors container health and restarts any that fail to keep the service running smoothly. This process ensures your application stays available and updated without manual intervention.

Practice

1. What is the main purpose of container orchestration in production environments?

easy

A. To manage and automate deployment, scaling, and operation of multiple containers

B. To write code inside containers

C. To create container images manually

D. To monitor CPU usage on a single container

Solution

1. Step 1: Understand container orchestration role

   Container orchestration automates managing many containers, including deployment and scaling.

2. Step 2: Compare options

   Only To manage and automate deployment, scaling, and operation of multiple containers describes managing and automating container groups, which is orchestration's goal.

3. Final Answer:

   To manage and automate deployment, scaling, and operation of multiple containers -> Option A

4. Quick Check:

   Orchestration = Manage & automate containers [OK]

Hint: Orchestration means managing many containers automatically [OK]

Common Mistakes:

• Confusing orchestration with coding inside containers
• Thinking orchestration is about creating images manually
• Believing orchestration only monitors single container stats

2. Which Docker Swarm command is used to create a new service in a cluster?

easy

A. docker service create

B. docker container run

C. docker swarm init

D. docker network create

Solution

1. Step 1: Identify command for creating services

   The command docker service create is used to start a new service in Docker Swarm.

2. Step 2: Eliminate other commands

   docker container run runs containers but not as a managed service; docker swarm init initializes the swarm; docker network create creates networks.

3. Final Answer:

   docker service create -> Option A

4. Quick Check:

   Service creation = docker service create [OK]

Hint: Service creation uses 'docker service create' command [OK]

Common Mistakes:

• Using 'docker container run' to create services
• Confusing swarm initialization with service creation
• Mixing network commands with service commands

3. What will be the output of the command docker service ls in a Docker Swarm cluster?

medium

A. List of all running containers on the host

B. List of all services running in the swarm with their replicas

C. List of all Docker images available locally

D. List of all networks created in Docker

Solution

1. Step 1: Understand the command purpose

   docker service ls shows all services in the swarm, including how many replicas each has.

2. Step 2: Compare with other options

   It lists services and replicas, not individual containers (<code>docker ps</code>), images (<code>docker images</code>), or networks (<code>docker network ls</code>).

3. Final Answer:

   List of all services running in the swarm with their replicas -> Option B

4. Quick Check:

   docker service ls = list swarm services [OK]

Hint: 'docker service ls' lists swarm services, not containers [OK]

Common Mistakes:

• Thinking it lists individual containers
• Confusing services with images or networks
• Expecting detailed container logs from this command

4. You run docker service scale myservice=5 but only 3 containers start. What is the likely cause?

medium

A. The command syntax is wrong

B. The service name is incorrect

C. Docker daemon is not running

D. Not enough resources on swarm nodes to run 5 replicas

Solution

1. Step 1: Analyze the scaling command

   The command syntax is correct and service name is assumed valid since some containers started.

2. Step 2: Identify resource constraints

   If only 3 replicas run instead of 5, likely the swarm nodes lack enough CPU/memory to start all replicas.

3. Final Answer:

   Not enough resources on swarm nodes to run 5 replicas -> Option D

4. Quick Check:

   Scaling fails due to resource limits [OK]

Hint: Scaling fails if swarm nodes lack resources [OK]

Common Mistakes:

• Assuming command syntax is wrong
• Thinking service name is invalid if some replicas run
• Ignoring resource limits on nodes

5. In a production Docker Swarm, how can you ensure your service stays running even if a node fails?

hard

A. Use 'docker container run' repeatedly on the same node

B. Run the service with a single replica on one node only

C. Set the service replicas to more than one so tasks run on multiple nodes

D. Disable swarm mode to avoid node failures

Solution

1. Step 1: Understand high availability in swarm

   Running multiple replicas spreads tasks across nodes, so if one node fails, others keep running the service.

2. Step 2: Evaluate options

   Single replica or running containers manually does not provide failover. Disabling swarm removes orchestration benefits.

3. Final Answer:

   Set the service replicas to more than one so tasks run on multiple nodes -> Option C

4. Quick Check:

   Multiple replicas = high availability [OK]

Hint: Use multiple replicas for failover in swarm [OK]

Common Mistakes:

• Running only one replica expecting failover
• Manually running containers without orchestration
• Disabling swarm mode to fix node failures