Docker Production Mastery - Complete Guide

⚙️ ENTRYPOINT vs CMD

Core Concept

ENTRYPOINT: Defines the main executable (fixed)

CMD: Provides default arguments (overridable)

⭐ Golden Rule: ENTRYPOINT = main command | CMD = default parameters

Basic Example

Dockerfile

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y curl

ENTRYPOINT ["curl"]
CMD ["https://example.com"]

bash

# Normal run
docker run myimage
→ Executes: curl https://example.com

# Override CMD
docker run myimage https://google.com
→ Executes: curl https://google.com

Why Both Together?

Flexibility: Different environments can use different args
K8s/Compose: Override CMD via YAML configuration
No Rebuild: Config changes without rebuilding image

✅ Best Practice: Always use exec form (JSON array)

Dockerfile

# ✅ Correct (Exec form)
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

# ❌ Avoid (Shell form)
ENTRYPOINT nginx -g "daemon off;"

🏗️ Multi-Stage Docker Builds

What is Multi-Stage Build?

Build your application in one stage, run it in another. Only copy what you need for production.

🎯 Result: Smaller images (~25MB vs ~800MB) + Better security + No build tools in production

Dockerfile

# ========================================
# STAGE 1: BUILD
# ========================================
FROM node:20-alpine AS build

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# ========================================
# STAGE 2: RUNTIME
# ========================================
FROM nginx:1.25-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/dist/public /usr/share/nginx/html

EXPOSE 80
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

Image Size Comparison

~800MB

Single Stage

→

Optimize

~25MB

Multi Stage

🔐 Security Best Practices

Three Pillars of Docker Security

Minimal Image: Only include what's necessary
Non-Root User: Run with least privileges
No Secrets: Inject at runtime only

⚠️ Critical: Without .dockerignore, secrets WILL leak into your image!

Essential .dockerignore

.dockerignore

node_modules
.git
.env
.env.local
*.log
Dockerfile
docker-compose.yml

❌ Wrong

Dockerfile

ENV DB_PASSWORD=secret123
# Baked into image!

✅ Correct

bash

docker run -e DB_PASSWORD=secret123
# Injected at runtime

🎯 Golden Rule: Image = blueprint | Secrets = keys (attached at runtime)

👤 Root vs Non-Root Users

Understanding Root

Root: Superuser with unlimited permissions (dangerous!)

Non-root: Limited user with restricted access (safe!)

⚠️ Security Risk: If attacker exploits your app running as root, they have FULL system access

🔔 Nginx Special Case: Nginx needs root to bind port 80, but workers run as non-root

bash

docker exec -it frontend ps aux

# Output:
USER     PID  COMMAND
root       1  nginx: master process  ← Binds port 80 only
nginx      7  nginx: worker process  ← Handles ALL traffic
nginx      8  nginx: worker process  ← Handles ALL traffic

🎯 Key Takeaway: Root only opens the gate, non-root does ALL the work

Strict Non-Root Setup (Port 8080)

Dockerfile

FROM nginx:alpine

RUN addgroup -S app && adduser -S app -G app
RUN sed -i 's/listen 80;/listen 8080;/' /etc/nginx/conf.d/default.conf
RUN chown -R app:app /var/cache/nginx /var/run /usr/share/nginx/html

USER app
EXPOSE 8080

🔄 Nginx Reverse Proxy

What is Reverse Proxy?

Nginx sits between browser and backend, forwarding requests transparently

🎯 Why? Browser only knows ONE address. Nginx decides: frontend files or backend API?

nginx.conf Configuration

nginx

upstream backend_api {
    server YOUR_BACKEND_IP:8000;
}

server {
    listen 80;
    root /usr/share/nginx/html;

    # Frontend routes
    location / {
        try_files $uri $uri/ /index.html;
    }

    # API proxy - THE MAGIC ✨
    location /api/ {
        proxy_pass http://backend_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

✅ Benefits:

No CORS issues
Backend IP hidden from public
SSL termination at one point
Load balancing capabilities

🚀 Production-Ready Dockerfile

Gold Standard Template

Combines: Multi-stage + Security + Nginx proxy + Proper user management

Dockerfile

# ============================================
# STAGE 1: BUILD
# ============================================
FROM node:20-alpine AS build

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# ============================================
# STAGE 2: RUNTIME
# ============================================
FROM nginx:1.25-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/dist/public /usr/share/nginx/html

EXPOSE 80
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

Build & Deploy

bash

# Build image
docker build -t frontend-app:v1.0 .

# Run container
docker run -d -p 80:80 --restart always frontend-app:v1.0

# Test
curl http://localhost
curl http://localhost/api/health

Production Checklist

✅ Multi-stage build
✅ .dockerignore present
✅ ENTRYPOINT + CMD
✅ Non-root workers
✅ Reverse proxy config
✅ Health endpoint

📚

Complete Docker Production Guide

A to Z - Everything You Need to Know

⚙️ ENTRYPOINT vs CMD

Core Concept

ENTRYPOINT: Defines the main executable (fixed)

CMD: Provides default arguments (overridable)

⭐ Golden Rule: ENTRYPOINT = main command | CMD = default parameters

Basic Example

Dockerfile

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y curl

ENTRYPOINT ["curl"]
CMD ["https://example.com"]

bash

# Normal run
docker run myimage
# Executes: curl https://example.com

# Override CMD
docker run myimage https://google.com
# Executes: curl https://google.com

Why Both Together?

Flexibility: Different environments (dev/prod) can use different args
Kubernetes/Compose: Can override CMD via YAML
No Rebuild: Configuration changes without rebuilding image

✅ Best Practice: Always use exec form (JSON array)

Dockerfile

# ✅ Correct (Exec form)
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

# ❌ Avoid (Shell form)
ENTRYPOINT nginx -g "daemon off;"

🏗️ Multi-Stage Docker Builds

What is Multi-Stage Build?

Build your application in one stage, run it in another. Only copy what you need for production.

🎯 Result: Smaller images (~25MB vs ~800MB), better security, no build tools in production

Complete Example

Dockerfile

# ========================================
# STAGE 1: BUILD
# ========================================
FROM node:20-alpine AS build

WORKDIR /app

# Copy deps first (caching optimization)
COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

# ========================================
# STAGE 2: RUNTIME
# ========================================
FROM nginx:1.25-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf

# Copy ONLY build output
COPY --from=build /app/dist/public /usr/share/nginx/html

EXPOSE 80
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

Image Size Comparison

~800MB

Single Stage

→

Optimize

~25MB

Multi Stage

Benefits

Smaller Images: 97% reduction in size
Better Security: No build tools in production
Faster Deployments: Less data to transfer
Cleaner Images: Only runtime dependencies

🔐 Security Best Practices

Three Pillars of Docker Security

Minimal Image: Only include what's necessary
Non-Root User: Run with least privileges
No Secrets in Image: Inject at runtime

1. Use .dockerignore

⚠️ Critical: Without .dockerignore, secrets WILL leak into your image!

.dockerignore

node_modules
.git
.env
.env.local
*.log
Dockerfile
docker-compose.yml

2. Never Hardcode Secrets

❌ Wrong

Dockerfile

ENV DB_PASSWORD=secret123

Baked into image

✅ Correct

bash

docker run -e DB_PASSWORD=secret123

Injected at runtime

🎯 Golden Rule: Image = blueprint | Secrets = keys (attached at runtime)

3. Use Minimal Base Images

Alpine Linux: ~5MB base image
Distroless: No shell, package manager
Scratch: Empty image for static binaries

4. Scan for Vulnerabilities

bash

# Using Docker Scout
docker scout cves myimage:latest

# Using Trivy
trivy image myimage:latest

👤 Root vs Non-Root Users

Understanding Root

Root: Superuser with unlimited permissions

Non-root: Limited user with restricted access

⚠️ Security Risk: If attacker exploits your app running as root, they have full system access

Nginx Special Case

🔔 Important: Nginx needs root to bind port 80, but workers run as non-root

bash

docker exec -it frontend ps aux

# Output:
# USER     PID  COMMAND
# root       1  nginx: master process  ← Binds port 80
# nginx      7  nginx: worker process  ← Handles traffic
# nginx      8  nginx: worker process  ← Handles traffic

🎯 Key Takeaway: Root only opens the gate, non-root does all the work

Understanding the Process Model

Master Process (root): Binds to privileged port 80, reads config, spawns workers
Worker Processes (nginx): Handle ALL incoming HTTP requests
Security: 99.99% of traffic handled by non-root processes

Strict Non-Root Setup (Port 8080)

Dockerfile

FROM nginx:alpine

RUN addgroup -S app && adduser -S app -G app
RUN sed -i 's/listen 80;/listen 8080;/' /etc/nginx/conf.d/default.conf
RUN chown -R app:app /var/cache/nginx /var/run /usr/share/nginx/html

USER app
EXPOSE 8080

✅ Best Practice: Use port 8080+ for strict non-root setup. Ports below 1024 require root.

🔄 Nginx Reverse Proxy

What is Reverse Proxy?

Nginx sits between the browser and backend servers, forwarding requests transparently to the appropriate backend service.

🎯 Why? Browser only knows ONE address. Nginx decides: frontend files or backend API?

How It Works

🌐 Browser → 🔄 Nginx (Port 80) → ⚡ Backend API (Port 8000)

nginx.conf Configuration

nginx

upstream backend_api {
    server 74.234.94.110:8000;
}

server {
    listen 80;
    root /usr/share/nginx/html;

    # Frontend routes
    location / {
        try_files $uri $uri/ /index.html;
    }

    # API proxy - THE MAGIC
    location /api/ {
        proxy_pass http://backend_api;
        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;
    }
}

Request Flow Example

Browser requests: http://myapp.com/api/users
Nginx receives: Request on port 80
Nginx checks: Path starts with /api/
Nginx forwards: To backend server at 74.234.94.110:8000
Backend responds: Data sent back through Nginx
Browser receives: Response (thinks it came from same origin)

Benefits

✅ Key Advantages:

No CORS Issues: Browser sees single origin
Backend Hidden: Real backend IP not exposed
SSL Termination: Handle HTTPS at one point
Load Balancing: Distribute traffic across multiple backends
Caching: Cache API responses at Nginx level
Rate Limiting: Protect backend from overload

Multiple Backend Services

nginx

upstream api_backend {
    server backend1.local:8000;
}

upstream auth_backend {
    server backend2.local:9000;
}

server {
    listen 80;

    location /api/ {
        proxy_pass http://api_backend;
    }

    location /auth/ {
        proxy_pass http://auth_backend;
    }
}

🚀 Production-Ready Dockerfile

Gold Standard

Combines: multi-stage + security + nginx proxy + proper user management

Dockerfile

# ============================================
# STAGE 1: BUILD
# ============================================
FROM node:20-alpine AS build

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# ============================================
# STAGE 2: RUNTIME
# ============================================
FROM nginx:1.25-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/dist/public /usr/share/nginx/html

EXPOSE 80
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

Required Files

tree

project-root/
├── Dockerfile
├── nginx.conf
├── .dockerignore
├── package.json
└── src/

Build & Run Commands

bash

# Build image
docker build -t frontend-app:v1.0 .

# Run container
docker run -d -p 80:80 --restart always frontend-app:v1.0

# Test endpoints
curl http://localhost
curl http://localhost/api/health

# View logs
docker logs frontend-app

# Stop container
docker stop frontend-app

Production Deployment Checklist

✅ Multi-stage build (~25MB final image)
✅ .dockerignore present (no secrets leaked)
✅ ENTRYPOINT + CMD (flexible configuration)
✅ Non-root workers (nginx user handles traffic)
✅ Reverse proxy configured (API routing setup)
✅ No secrets in image (runtime injection)

Environment-Specific Configs

bash

# Development
docker run -p 3000:80 -e ENV=dev myapp:v1.0

# Staging
docker run -p 80:80 -e ENV=staging myapp:v1.0

# Production
docker run -d -p 80:80 \
  -e ENV=production \
  -e API_URL=https://api.prod.com \
  --restart always \
  myapp:v1.0

💼 Interview-Ready Answers

Q1: What's the difference between ENTRYPOINT and CMD?

A: ENTRYPOINT defines the main executable that always runs. CMD provides default arguments that can be overridden at runtime. Together, they provide flexibility with safety - you ensure the correct program runs while allowing configuration changes.

Example: With ENTRYPOINT ["curl"] and CMD ["https://example.com"], running docker run myimage executes curl https://example.com, but docker run myimage https://google.com executes curl https://google.com.

Q2: Why use multi-stage builds?

A: Multi-stage builds reduce the final image size and attack surface by separating build-time dependencies from runtime dependencies. Build tools stay in the build stage, only runtime artifacts go to production. This results in images that are ~97% smaller (25MB vs 800MB), more secure, and faster to deploy.

Key Benefits:

Smaller images (faster deployments)
Better security (no build tools in production)
Cleaner images (only runtime dependencies)
Faster CI/CD pipelines

Q3: Is running Nginx as root insecure?

A: The master process runs as root only to bind privileged port 80, but all request-handling workers run as the unprivileged nginx user. This means 99.99% of traffic is handled by non-root processes, limiting the blast radius of any exploit. For maximum security, you can configure Nginx to use port 8080 and run everything as non-root.

Process Breakdown:

Master (root): Binds port, reads config, spawns workers (1 process)
Workers (nginx): Handle all HTTP requests (multiple processes)

Q4: How does Nginx reverse proxy work?

A: Nginx sits between the client and backend servers. When a request comes in, Nginx examines the URL path and forwards it to the appropriate backend server based on location blocks. For example, requests to /api/* go to the API server while / serves static files. The client only knows one endpoint, eliminating CORS issues. Nginx also handles SSL termination, load balancing, and caching.

Key Advantages:

Single origin (no CORS)
Backend IP hidden
SSL at one point
Load balancing
Caching layer

Q5: How do you handle secrets in Docker?

A: Never hardcode secrets in Dockerfile or ENV directives. Instead, inject secrets at runtime using:

Environment variables: docker run -e DB_PASSWORD=secret
Docker secrets (Swarm): docker secret create db_password -
Kubernetes secrets: kubectl create secret generic app-secrets
External services: HashiCorp Vault, AWS Secrets Manager

Key principle: Image = Blueprint, Secrets = Keys (attached at runtime)

Q6: What's the purpose of .dockerignore?

A: .dockerignore prevents sensitive files and unnecessary data from being copied into the Docker image during build. Without it, secrets in .env files, node_modules, git history, and logs could leak into your image layers. This improves security and reduces image size.

✨ Final Recommendations

✅ Always Do:

Use multi-stage builds for production
Include .dockerignore file
Inject secrets at runtime, never hardcode
Use specific version tags, not :latest
Scan images for vulnerabilities regularly
Run workers as non-root users
Use nginx for reverse proxy in production
Keep base images minimal (Alpine, Distroless)
Layer caching optimization (deps before source)

❌ Never Do:

Include secrets in Dockerfile or image layers
Use :latest tag in production environments
Run applications as root unnecessarily
Skip .dockerignore file
Expose build tools in production images
Hardcode environment-specific configs
Copy entire project directory without filtering
Use shell form for ENTRYPOINT/CMD

🎓

You're Production Ready!

You now have complete knowledge of Docker production best practices. From ENTRYPOINT/CMD to multi-stage builds, security, and nginx proxy configuration.

✅ Multi-stage builds | ✅ Security hardening | ✅ Non-root users
✅ Reverse proxy | ✅ Production deployment | ✅ Interview ready

👨‍💼

Created By

Ritesh Sharma

DevOps Engineer | Cloud Architect

Azure • Terraform • CI/CD • Kubernetes • Cloud Automation