Docker in Production

# CHAPTER 16

Docker in Production #

1. Introduction #

2. Learning Objectives #

• Configure automated Restart Policies to recover from crashes.

• Implement Docker Health Checks to detect frozen applications.

• Understand the limitations of raw Docker Compose in production.

• Define Container Orchestration.

• Prepare a container for a production deployment.

3. Beginner-Friendly Explanation #

• Local Development: The employee falls asleep (The app freezes). You walk over, tap them on the shoulder, and wake them up (You type docker restart).

• Production (Restart Policies): You install a mechanical chair. If the employee stops typing for 5 minutes, the chair automatically tips them onto the floor, waking them up immediately.

• Production (Health Checks): The employee is awake, but they are wearing a blindfold. They are technically "Running", but they are useless. You install a robot that asks the employee a question every 30 seconds. If the employee gives the wrong answer, the robot fires them and hires a new employee instantly.

4. Restart Policies #

Common policies:

• no: The default. Do not restart.

• always: Always restart the container if it stops. If you reboot the physical host server, Docker will automatically launch this container on startup.

• unless-stopped: Always restart the container, *unless* you manually typed docker stop. (This is the industry standard for production web servers).

*In Docker Compose:*

services:
  web:
    image: nginx:alpine
    restart: unless-stopped

5. Health Checks #

You tell Docker: "Every 30 seconds, send an HTTP request to localhost/api/health. If it fails 3 times in a row, mark the container as UNHEALTHY."

*In Docker Compose:*

services:
  api:
    image: my-node-api
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

6. The Limitation of Docker Compose #

7. Introduction to Container Orchestration #

• Scheduling: It looks at the 5 servers, finds the one with the most free RAM, and launches the container there.

• Self-Healing: If Server A catches fire, the Orchestrator instantly notices the 10 containers on it died, and automatically recreates them on Servers B, C, and D.

• Scaling: If traffic spikes, it commands: "Scale the web container from 2 replicas to 20 replicas."

The two most famous Orchestrators are Docker Swarm (built into Docker) and Kubernetes (the global industry standard).

8. Mini Project: A Production-Ready docker-compose.yml #

Step-by-Step Tutorial: Review this production-grade Compose file:

version: '3.8'

services:
  database:
    image: postgres:15-alpine
    restart: always # Auto-recover the database
    environment:
      - POSTGRES_PASSWORD=${DB_PASS} # Secure secrets via .env
    volumes:
      - db-data:/var/lib/postgresql/data # Persistent storage

  web:
    image: my-company/frontend:v2.1.0 # Strict version tagging (no 'latest')
    restart: unless-stopped
    ports:
      - "80:80"
    depends_on:
      - database

volumes:
  db-data:

This architecture is self-healing, data-persistent, strictly versioned, and secured against leaked secrets.

9. Best Practices #

• Graceful Shutdowns: When you update an image, Docker sends a SIGTERM signal to the old container, asking it to stop politely. If your application code ignores this signal, Docker waits 10 seconds and then forcefully kills (SIGKILL) the container, potentially dropping active user database transactions! Always program your applications to handle shutdown signals gracefully.

10. Common Mistakes #

• Ignoring Log Management: As discussed in Chapter 13, running containers in production without a log rotation limit will eventually fill the host server's hard drive to 100%, causing a catastrophic total system crash.

11. Exercises #

1. 1. Contrast a container crashing (the process stopping) with a container becoming "Unhealthy". Why are Health Checks necessary if Restart Policies already exist?

1. 2. Why is raw docker-compose insufficient for an enterprise architecture requiring High Availability across multiple physical data centers?

12. FAQs #

13. Interview Questions #

• Q: Explain the mechanical difference between the always and unless-stopped Docker restart policies. In a production web server environment, which policy is generally preferred and why?

• Q: A Node.js API container is technically in the "Up" state, but it is entirely unresponsive to HTTP requests due to a deadlocked thread. Describe the Docker feature you would implement to automatically detect and remediate this frozen state.

14. Summary #

15. Next Chapter Recommendation #