Container orchestration in production in Docker - Commands & Configuration

Introduction

Managing many containers manually is hard and error-prone. Container orchestration automates running, scaling, and managing containers in production so your apps stay reliable and efficient.

When you want to run multiple containers that work together as one app and keep them running smoothly.

When you need to update your app without downtime by replacing containers one by one.

When your app needs to handle more users by automatically adding more containers.

When you want to recover quickly if a container crashes by restarting it automatically.

When you want to manage container networking and storage easily across many servers.

Config File - docker-compose.yml

docker-compose.yml

version: '3.9'
services:
  web:
    image: nginx:1.23
    ports:
      - "8080:80"
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
  app:
    image: my-app:latest
    depends_on:
      - db
    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure
  db:
    image: postgres:15
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data: {}

This docker-compose.yml file defines three services: web, app, and db.

web runs Nginx and exposes port 8080 on the host mapped to port 80 in the container. It runs 3 copies (replicas) for load balancing and restarts if it fails.

app runs your application image, depends on the database, runs 2 replicas, and restarts on failure.

db runs PostgreSQL with environment variables for user and password, and stores data persistently in a named volume db-data.

This setup helps run multiple containers together with automatic restarts and scaling.

Commands

This command deploys the app stack defined in the docker-compose.yml file to Docker Swarm mode, creating and managing all services together.

Terminal

docker stack deploy -c docker-compose.yml myapp

Expected Output

Creating network myapp_default

Creating service myapp_web

Creating service myapp_app

Creating service myapp_db

→

-c - Specifies the compose file to use for deployment

Lists all running services in the Docker Swarm to verify that the app services are up and running.

Terminal

docker service ls

Expected Output

ID                  NAME                MODE                REPLICAS            IMAGE               PORTS

xk3j4k5l6m7n        myapp_web           replicated          3/3                 nginx:1.23          *:8080->80/tcp

p9q8r7s6t5u4        myapp_app           replicated          2/2                 my-app:latest

z1y2x3w4v5u6        myapp_db            replicated          1/1                 postgres:15

Shows detailed status of all tasks (containers) running for the web service to check if all replicas are healthy.

Terminal

docker service ps myapp_web

Expected Output

ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE           ERROR               PORTS

abc123def456        myapp_web.1         nginx:1.23          node1               Running             Running 2 minutes ago

def456ghi789        myapp_web.2         nginx:1.23          node2               Running             Running 2 minutes ago

ghi789jkl012        myapp_web.3         nginx:1.23          node3               Running             Running 2 minutes ago

Updates the web service to use a newer Nginx image version 1.24, rolling out the update without downtime.

Terminal

docker service update --image nginx:1.24 myapp_web

Expected Output

myapp_web

overall progress: 3 out of 3 tasks

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

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

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

verify: Service converged

→

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

Key Concept

If you remember nothing else from this pattern, remember: container orchestration automates running, scaling, and recovering multiple containers together to keep your app reliable in production.

Common Mistakes

Running multiple containers manually without orchestration tools.

It becomes hard to manage, scale, and recover containers, leading to downtime and errors.

Use orchestration tools like Docker Swarm with docker-compose files to manage containers as a group.

Not specifying restart policies in the compose file.

Containers won't restart automatically if they crash, causing service outages.

Add restart_policy under deploy to ensure containers restart on failure.

Updating container images by stopping and starting containers manually.

This causes downtime and can lead to inconsistent app states.

Use docker service update to roll out updates smoothly without downtime.

Summary

Use a docker-compose.yml file to define multiple services with replicas and restart policies.

Deploy the stack with docker stack deploy to run all services together in Docker Swarm mode.

Check service status with docker service ls and docker service ps to ensure containers run correctly.

Update services smoothly using docker service update with the new image version.

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