Docker Volumes and Networking Explained — Data, Containers, and Real-World Patterns

#!/bin/bash
# ── STEP 1: Create a named volume Docker will manage ──────────────────────────
docker volume create postgres_data

# ── STEP 2: Inspect the volume to see where Docker actually stores it ─────────
docker volume inspect postgres_data
# Output shows the 'Mountpoint' on the host — usually /var/lib/docker/volumes/...

# ── STEP 3: Run Postgres and mount our volume to its data directory ───────────
# The -v flag maps: <volume_name>:<path_inside_container>
docker run -d \
  --name postgres_primary \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_PASSWORD=securepass123 \
  -e POSTGRES_DB=appdb \
  -v postgres_data:/var/lib/postgresql/data \
  postgres:15-alpine

# ── STEP 4: Write some data into the database ─────────────────────────────────
docker exec -it postgres_primary psql -U appuser -d appdb \
  -c "CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);"
docker exec -it postgres_primary psql -U appuser -d appdb \
  -c "INSERT INTO users (name) VALUES ('Alice'), ('Bob');"

# ── STEP 5: Destroy the container completely ──────────────────────────────────
# Without a volume this would delete all our data. Watch what happens instead.
docker rm -f postgres_primary

# ── STEP 6: Start a BRAND NEW container using the SAME volume ─────────────────
docker run -d \
  --name postgres_restored \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_PASSWORD=securepass123 \
  -e POSTGRES_DB=appdb \
  -v postgres_data:/var/lib/postgresql/data \
  postgres:15-alpine

# ── STEP 7: Prove the data survived the container deletion ────────────────────
docker exec -it postgres_restored psql -U appuser -d appdb \
  -c "SELECT * FROM users;"

# ── CLEANUP (optional — only run when you're done experimenting) ──────────────
# docker rm -f postgres_restored && docker volume rm postgres_data

#!/bin/bash
# ── STEP 1: Create a user-defined bridge network ──────────────────────────────
# This is what enables DNS-based container discovery
docker network create \
  --driver bridge \
  --subnet 172.28.0.0/16 \
  app_internal_network

# ── STEP 2: Start a Redis cache container on our custom network ───────────────
# Notice: we do NOT publish Redis's port to the host (no -p flag)
# Only containers on app_internal_network can reach it — that's intentional
docker run -d \
  --name redis_cache \
  --network app_internal_network \
  redis:7-alpine

# ── STEP 3: Start an API container on the same network ───────────────────────
# It can reach Redis using the hostname 'redis_cache' — not an IP address
docker run -d \
  --name api_server \
  --network app_internal_network \
  -p 3000:3000 \
  -e REDIS_HOST=redis_cache \
  -e REDIS_PORT=6379 \
  node:20-alpine \
  sh -c "npm install -g redis-cli && sleep infinity"

# ── STEP 4: Prove DNS resolution works inside the network ─────────────────────
# From inside api_server, ping redis_cache by NAME (not IP)
docker exec api_server ping -c 3 redis_cache

# ── STEP 5: Inspect the network to see both containers connected ──────────────
docker network inspect app_internal_network \
  --format '{{range .Containers}}{{.Name}}: {{.IPv4Address}}{{"\n"}}{{end}}'

# ── STEP 6: Verify Redis is NOT reachable from your host machine directly ─────
# This should fail — Redis is internal only, which is exactly what we want
curl -v telnet://localhost:6379 2>&1 | head -5

# ── CLEANUP ───────────────────────────────────────────────────────────────────
# docker rm -f redis_cache api_server && docker network rm app_internal_network

# docker-compose.production.yml
# Runs a Node.js API backed by Postgres with persistent storage
# and a private network — no exposed database ports

version: "3.9"

services:

  # ── Postgres Database ─────────────────────────────────────────────────────
  database:
    image: postgres:15-alpine
    container_name: postgres_primary
    restart: unless-stopped          # Restart on crash, but respect manual stops
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: securepass123
      POSTGRES_DB: appdb
    volumes:
      # Named volume keeps data safe across container replacements
      - postgres_data:/var/lib/postgresql/data
      # Seed script runs once on first volume initialization
      - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql:ro
    networks:
      - backend_network
    healthcheck:
      # pg_isready exits 0 when Postgres is accepting connections
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s      # Check every 10 seconds
      timeout: 5s        # Fail check if no response in 5s
      retries: 5         # Mark unhealthy after 5 failures
      start_period: 30s  # Grace period before checks start
    # NO ports: section — database is intentionally unreachable from host

  # ── Node.js REST API ──────────────────────────────────────────────────────
  api:
    build:
      context: ./api
      dockerfile: Dockerfile
    container_name: node_api
    restart: unless-stopped
    ports:
      - "3000:3000"      # Only the API is exposed to the outside world
    environment:
      # Uses the service name 'database' as the hostname — Docker DNS resolves it
      DATABASE_URL: postgresql://appuser:securepass123@database:5432/appdb
      NODE_ENV: production
      PORT: 3000
    volumes:
      # Bind mount for uploaded files — you want these on the host for backups
      - ./uploads:/app/uploads
    networks:
      - backend_network
    depends_on:
      database:
        # 'service_healthy' waits for the healthcheck to pass — not just container start
        condition: service_healthy

# ── Named Volumes ─────────────────────────────────────────────────────────────
# Declared here so Docker Compose manages their lifecycle
volumes:
  postgres_data:
    driver: local
    # Optional: add 'external: true' if this volume is managed outside Compose

# ── Networks ──────────────────────────────────────────────────────────────────
networks:
  backend_network:
    driver: bridge
    # ipam config is optional but useful when you need predictable subnets
    ipam:
      config:
        - subnet: 172.29.0.0/16