Docker in Production

Decision signals

• Stay on Compose / single server — one or two services, predictable traffic, team < 5, no multi-AZ requirement, deploy cadence weekly or slower
• Consider Docker Swarm — 3–10 nodes, need HA without hiring a platform team, rolling updates across a small fleet
• Move to Kubernetes — dozens of services, autoscaling, CRDs/operators, multi-tenant namespaces, GitOps as standard, or compliance mandates centralized policy

Compose / single server vs Swarm vs Kubernetes

flowchart TD
  A["Need production containers?"]
  B["Single host / VPS\nCompose + reverse proxy"]
  C["3–10 nodes, small team\nDocker Swarm"]
  D["Platform team / multi-service\nKubernetes"]
  A --> Q1{"Multi-AZ or\nautoscaling required?"}
  Q1 -->|No| Q2{"More than one\nphysical host?"}
  Q1 -->|Yes| D
  Q2 -->|No| B
  Q2 -->|Yes| Q3{"Want K8s-level\necosystem?"}
  Q3 -->|No| C
  Q3 -->|Yes| D

The 12-factor logging contract

1. Application writes structured (JSON) or plain text lines to stdout/stderr
2. Docker logging driver captures the stream per container
3. Host agent or driver forwards to centralized store (Loki, CloudWatch, ELK, Datadog)
4. Retention, search, and alerting live outside the container lifecycle

Default: json-file driver

Unless configured otherwise, Docker uses the json-file driver—each log line becomes a JSON object in /var/lib/docker/containers/<id>/<id>-json.log. Convenient for docker logs, dangerous without rotation (disk fills → node down).

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5",
    "labels": "service,env"
  }
}

Set globally in /etc/docker/daemon.json or per-container with --log-opt max-size=10m --log-opt max-file=5. max-size rotates when a file exceeds the threshold; max-file keeps N rotated files (roughly 50 MB total in the example above).

Alternative logging drivers

Per-service override in Compose

services:
  api:
    image: myorg/api:1.4.2
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"
        tag: "{{.Name}}/{{.ID}}"

HEALTHCHECK parameters

Probe types

Dockerfile and Compose examples

# Lightweight HTTP check — install curl in builder only if needed
HEALTHCHECK --interval=15s --timeout=3s --start-period=30s --retries=3 \
  CMD curl -fsS http://127.0.0.1:8080/actuator/health || exit 1

services:
  api:
    image: myorg/api:1.4.2
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 40s

Liveness vs readiness

$ docker inspect --format '{{json .State.Health}}' api
{"Status":"healthy","FailingStreak":0,"Log":[{"ExitCode":0,...}]}

$ docker ps --filter health=unhealthy
CONTAINER ID   IMAGE          STATUS
a1b2c3d4e5f6   myorg/api:1.4   Up 2 min (unhealthy)

Compose: pull and up (rolling recreate)

docker compose pull && docker compose up -d recreates containers whose image digest changed. With depends_on: condition: service_healthy, dependent services wait for upstream health. Default behavior briefly drops connections during container swap—acceptable for internal tools, risky for public APIs without a reverse proxy buffer.

# Typical immutable deploy on a single host
docker compose pull
docker compose up -d --remove-orphans --wait

# --wait (Compose v2.23+): blocks until healthchecks pass

Blue-green with nginx

Run two identical stacks (blue and green) on different host ports or Docker networks. nginx upstream points at the active color; deploy updates the idle color, health-check it, then flip proxy_pass and reload nginx (nginx -s reload is graceful—existing connections drain).

sequenceDiagram
  participant LB as nginx
  participant Blue as api-blue :8081
  participant Green as api-green :8082
  LB->>Blue: 100% traffic
  Note over Green: Deploy new version
  Green->>Green: healthcheck passes
  LB->>Green: reload upstream
  LB->>Green: 100% traffic
  Note over Blue: drain then stop

upstream api_active {
  server api-blue:8080;
  # server api-green:8080;  # uncomment to switch
}

server {
  location / {
    proxy_pass http://api_active;
    proxy_next_upstream error timeout http_502;
  }
}

Traefik: labels for traffic shifting

Traefik discovers backends via Docker labels. Run blue and green services with different router priorities or use weighted services (Traefik Enterprise / experimental weighted round-robin) to shift traffic gradually.

services:
  api-green:
    image: myorg/api:1.5.0
    labels:
      - traefik.enable=true
      - traefik.http.routers.api.rule=Host(`api.example.com`)
      - traefik.http.routers.api.priority=100
      - traefik.http.services.api.loadbalancer.server.port=8080
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      start_period: 30s

  api-blue:
    image: myorg/api:1.4.2
    labels:
      - traefik.enable=true
      - traefik.http.routers.api-blue.rule=Host(`api.example.com`)
      - traefik.http.routers.api-blue.priority=50
      - traefik.http.services.api-blue.loadbalancer.server.port=8080

Memory and CPU limits

services:
  api:
    image: myorg/api:1.4.2
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 2G
        reservations:
          cpus: "0.5"
          memory: 512M

JVM sizing example

A container with --memory=2g must not run a JVM that assumes host RAM. Use container-aware flags so the heap respects cgroup limits:

ENV JAVA_TOOL_OPTIONS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"
# 2g limit → ~1.5g heap, ~500m for metaspace, threads, native buffers

Observability stack

# Quick capacity check
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

# cAdvisor (publish metrics on :8080)
docker run -d --name=cadvisor --privileged \
  -p 8080:8080 \
  -v /:/rootfs:ro -v /var/run:/var/run:ro \
  -v /sys:/sys:ro -v /var/lib/docker/:/var/lib/docker:ro \
  gcr.io/cadvisor/cadvisor:latest

Example Prometheus alert: fire when container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.9 for 5m—action before OOM kill.

Tooling map

Podman vs Docker Engine

# RHEL: install compatibility shim
sudo dnf install podman podman-docker buildah skopeo

# Familiar workflow — docker is podman
docker run -d --name api -p 8080:8080 registry.example.com/api:1.4.2
docker ps

# Rootless podman (default for normal users)
podman run -d quay.io/podman/hello

# Generate systemd user service for a container
podman generate systemd --new --name api > ~/.config/systemd/user/api.service
systemctl --user enable --now api.service

OpenShift specifics

• CRI-O runs workloads on worker nodes; developers typically never SSH to nodes
• ImageStreams — OpenShift-native image abstraction: tracks tags, triggers redeploys on new push, mirrors external registries
• Restricted SCCs — Security Context Constraints replace ad-hoc --cap-add; containers run as arbitrary non-root UIDs
• BuildConfigs — cluster-native builds (Dockerfile, S2I) producing ImageStream tags—similar goals to CI pipelines elsewhere
• Routes — HAProxy-based ingress with TLS edge termination; analogous to Ingress + cert-manager on vanilla K8s