Production-Ready Docker Deployment Architecture

# Production-Ready Docker Deployment Architecture

Introduction

Production-ready Docker deployment requires careful architecture planning around scalability, reliability, security, and observability. This tutorial covers multi-container orchestration, load balancing, rolling updates, rollback procedures, health checks, and high availability patterns.

Learning Objectives

By the end of this tutorial, you will be able to:

• Design production Docker deployment architecture
• Implement load balancing for containerized applications
• Configure rolling updates and rollback procedures
• Set up health checks and auto-restart policies
• Design for high availability
• Implement resource limits and quality of service
• Monitor production Docker deployments

Technical Background

Production Architecture

Load Balancer (NGINX/HAProxy/Cloud LB)
    |
    v
Docker Host 1 --- Container 1 (App)
    |         --- Container 2 (App)
Docker Host 2 --- Container 3 (App)
    |         --- Container 4 (App)
    |
    v
Shared Storage (NFS/Cloud Storage)
    |
    v
External Database (RDS/Azure SQL/Managed)

High Availability Patterns

| Pattern | Description | |---------|-------------| | Multiple hosts | Run containers across multiple Docker hosts | | Load balancer | Distribute traffic across containers | | Health checks | Detect and remove unhealthy containers | | Rolling updates | Zero-downtime deployments | | Rollback | Revert to previous version on failure | | Resource limits | Prevent resource exhaustion |

Prerequisites

• Docker and Docker Compose installed
• Multiple Docker hosts (for multi-host deployment)
• Load balancer (NGINX, HAProxy, or cloud LB)
• Container registry

Hardware and Software Requirements

| Component | Requirement | |-----------|-------------| | Docker | v24+ | | Docker Compose | v2+ | | Load Balancer | NGINX, HAProxy, or cloud LB | | Container Registry | Docker Hub, ECR, ACR, or GCR |

Step-by-Step Implementation

Phase 1: Production Dockerfile

# Multi-stage build for production
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=10s --start-period=40s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]

Phase 2: Production Docker Compose

# docker-compose.prod.yml
version: '3.8'
services:
  app:
    image: myregistry.com/myapp:{{VERSION}}
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=${DATABASE_URL}
      - REDIS_URL=${REDIS_URL}
    secrets:
      - db_password
      - redis_password
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
    resources:
      limits:
        cpus: '0.5'
        memory: 512M
      reservations:
        cpus: '0.25'
        memory: 256M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    networks:
      - app-network
    restart: unless-stopped

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
    networks:
      - app-network

secrets:
  db_password:
    file: ./secrets/db_password
  redis_password:
    file: ./secrets/redis_password

networks:
  app-network:
    driver: bridge

volumes:
  postgres_data:

Phase 3: Load Balancer Configuration

#### NGINX Load Balancer

# nginx.conf
upstream myapp {
    server container1:3000;
    server container2:3000;
    server container3:3000;
}

server {
    listen 80;
    server_name myapp.example.com;

    location / {
        proxy_pass http://myapp;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
    
    location /health {
        access_log off;
        return 200 "healthy";
        add_header Content-Type text/plain;
    }
}

Phase 4: Rolling Updates

# Update application image
docker compose -f docker-compose.prod.yml up -d --scale app=5

# Docker Compose handles rolling update automatically
# Based on deploy.update_config settings

# Check update status
docker compose ps

# Rollback if needed
docker compose -f docker-compose.prod.yml up -d --scale app=3
# Or use specific previous image version

#### Manual Rolling Update

# Scale up new version first
docker compose up -d --scale app=6 --no-deps app

# Gradually shift traffic
# Update load balancer configuration

# Scale down old version
docker compose up -d --scale app=3 --no-deps app

Phase 5: Health Checks and Auto-Restart

# Health check configuration in compose
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

# Restart policy
restart: unless-stopped

# Deploy restart policy
deploy:
  restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 3
    window: 120s

Phase 6: Resource Management

# Resource limits in compose
deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M
    reservations:
      cpus: '0.25'
      memory: 256M

Phase 7: Backup and Disaster Recovery

#### Application Data Backup

# Backup named volume
docker run --rm \
  -v postgres_data:/source \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/postgres-backup-$(date +%Y%m%d).tar.gz -C /source .

#### Application State Backup

# Backup application configuration
tar czf app-config-backup.tar.gz \
  docker-compose.prod.yml \
  .env \
  nginx.conf \
  secrets/

Phase 8: Monitoring and Alerting

# Monitor container resources
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"

# Check container health
docker inspect --format='{{.State.Health.Status}}' <container-name>

# View recent events
docker events --since=1h --filter container=<container-name>

# Check logs for errors
docker logs --tail=100 <container-name>

Expected Output

• Production Docker deployment architecture defined
• Load balancing configured
• Rolling updates working
• Health checks and auto-restart configured
• Resource limits applied
• Backup and disaster recovery procedures documented

Verification Procedures

| Check | Command | Expected Result | |-------|---------|-----------------| | Services running | `docker compose ps` | All services healthy with replicas | | Load balancing | `curl http://localhost/health` | Returns healthy from different containers | | Rolling update | `docker compose up -d --scale app=5` | Zero-downtime update | | Rollback | Revert to previous image | Previous version running | | Health check | `docker inspect --format='{{.State.Health.Status}}'` | healthy |

Troubleshooting Scenarios

| Issue | Diagnosis | Resolution | |-------|-----------|------------| | Rolling update fails | Health check failing | Fix application; increase start_period | | Container not restarting | Restart policy not met | Check logs; fix crash cause | | Load balancer not routing | Backend containers unhealthy | Check health; verify network | | Resource exhaustion | No limits set | Add resource limits in compose |

Best Practices

• **Use image tags:** Never use `latest` in production
• **Set resource limits:** Prevent container from consuming all host resources
• **Configure health checks:** Detect unhealthy containers automatically
• **Use rolling updates:** Zero-downtime deployments
• **Implement rollback:** Quick recovery from bad deployments
• **Use secrets:** Never hardcode passwords or API keys
• **Monitor resources:** Track CPU and memory usage
• **Backup regularly:** Volume and configuration backups

Security Considerations

• **Run as non-root:** Add USER directive to Dockerfile
• **Drop capabilities:** --cap-drop=ALL at runtime
• **Read-only filesystem:** --read-only where possible
• **Image scanning:** Scan for vulnerabilities before deployment
• **Network segmentation:** Isolate application tiers
• **TLS for load balancer:** Terminate HTTPS at load balancer

Conclusion

Production-ready Docker deployment architecture requires careful planning around scalability, reliability, and security. By implementing multi-container orchestration, load balancing, rolling updates, health checks, resource limits, and backup procedures, you can run containerized applications reliably in production environments.

References

• Docker Compose Production: https://docs.docker.com/compose/production/
• Docker Swarm: https://docs.docker.com/engine/swarm/
• NGINX Load Balancing: https://docs.nginx.com/nginx/admin-guide/load-balancer/
• Docker Health Checks: https://docs.docker.com/engine/reference/builder/#healthcheck
• Docker Security: https://docs.docker.com/engine/security/