Docker Intermediate

FROM node:20-alpine

WORKDIR /app

# Create a system group and user with no login shell and no password
# -S = system account, -G = assign to group
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Install dependencies as root (required to write to /app)
COPY package*.json ./
RUN npm ci --only=production

COPY . .

# Give our new user ownership of the app directory
RUN chown -R appuser:appgroup /app

# SWITCH to the non-root user. All subsequent instructions run as appuser.
USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

# ❌ WRONG — This bakes the secret into the image permanently
# ENV DATABASE_PASSWORD=supersecret123  ← NEVER do this in a Dockerfile

# ✅ CORRECT — Pass secrets as environment variables at runtime
docker run -e DATABASE_PASSWORD=supersecret123 myapp

# ✅ BETTER — Load from a .env file (which you NEVER commit to Git)
docker run --env-file .env myapp

# ✅ BEST for production — Docker Swarm / Compose secrets
# (covered in the Swarm lesson — secrets are encrypted at rest)

# In docker-compose.yml:
# secrets:
#   db_password:
#     file: ./secrets/db_password.txt
#
# The secret is mounted as a file at /run/secrets/db_password
# inside the container — never as an environment variable.

# Quick vulnerability summary for a local image
docker scout quickview myapp:prod

# Full CVE report with severity levels and fix recommendations
docker scout cves myapp:prod

# Check if a newer base image would fix vulnerabilities
docker scout recommendations myapp:prod

# Output example:
# ✓  No critical vulnerabilities found
# !  3 high vulnerabilities in openssl 3.0.2
# →  Upgrade base image to alpine:3.19 to fix all 3

# --read-only makes the container filesystem read-only
# --tmpfs adds a temporary in-memory writable directory
# (needed for things like /tmp for temp files)
docker run \
  --read-only \
  --tmpfs /tmp \
  --tmpfs /app/cache \
  -p 8080:8080 \
  myapp:prod

# In docker-compose.yml:
# services:
#   web:
#     read_only: true
#     tmpfs:
#       - /tmp

# ── WEB SERVER (HTTP endpoint check) ──────────────────────
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci --only=production

# Check the /health endpoint every 30s.
# Wait 20s before starting checks (app needs time to boot).
# 3 failures = unhealthy.
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

CMD ["node", "server.js"]

# ── DATABASE (TCP port check) ──────────────────────────────
FROM postgres:16-alpine

# pg_isready checks if PostgreSQL is accepting connections
HEALTHCHECK --interval=10s --timeout=5s --retries=5 \
  CMD pg_isready -U postgres || exit 1

# ── REDIS ──────────────────────────────────────────────────
FROM redis:7-alpine

HEALTHCHECK --interval=10s --timeout=3s \
  CMD redis-cli ping | grep -q PONG || exit 1

# See health status in container listing
docker ps

# STATUS column will show one of:
#   Up 5 minutes (health: starting)   ← within start-period
#   Up 5 minutes (healthy)            ← all good
#   Up 5 minutes (unhealthy)          ← needs investigation!

# Get detailed health check history (last 5 checks)
docker inspect --format '{{json .State.Health}}' <container_id> | jq

# Output shows each check result, exit code, and output:
# {
#   "Status": "healthy",
#   "FailingStreak": 0,
#   "Log": [
#     { "ExitCode": 0, "Output": "OK\n", "Start": "2024-..." }
#   ]
# }

# ── MEMORY LIMITS ──────────────────────────────────────────

# Hard memory limit: container is killed if it exceeds 512MB
docker run --memory 512m myapp

# Soft limit (reservation): Docker tries to keep usage below
# this, but doesn't kill the container if it goes over.
# Used by Swarm for scheduling decisions.
docker run --memory 512m --memory-reservation 256m myapp

# Disable swap for the container (force it to use RAM only)
docker run --memory 512m --memory-swap 512m myapp

# ── CPU LIMITS ─────────────────────────────────────────────

# Limit to 1.5 CPU cores (can use fractional values)
docker run --cpus 1.5 myapp

# Set relative CPU weight (default: 1024)
# A container with 512 gets half the CPU of one with 1024
# when CPU is contended
docker run --cpu-shares 512 myapp

# Pin the container to specific CPU cores (e.g., cores 0 and 1 only)
docker run --cpuset-cpus "0,1" myapp

services:

  web:
    image: myapp:prod
    deploy:
      resources:
        limits:
          cpus: '0.5'        # Hard cap: 50% of one CPU core
          memory: 256M      # Hard cap: 256 megabytes RAM
        reservations:
          cpus: '0.1'        # Soft reservation for scheduling
          memory: 128M

  database:
    image: postgres:16
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G       # Databases need more memory — be generous
        reservations:
          memory: 512M

# Real-time resource usage for ALL running containers (like top, for Docker)
docker stats

# Output:
# CONTAINER    CPU %   MEM USAGE / LIMIT   MEM %   NET I/O
# web          0.5%    45MB / 256MB        17.5%   1.2MB / 800KB
# database     1.2%    312MB / 1GB         30.4%   500KB / 120KB

# Stats for a single container (by name or ID)
docker stats web

# One-shot stats snapshot (no live refresh)
docker stats --no-stream

services:

  # Nginx is the only container exposed to the outside world.
  # It sits on the "frontend" network only.
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    networks:
      - frontend

  # The web app lives on BOTH networks —
  # it receives traffic from nginx (frontend)
  # and talks to the database (backend).
  web:
    build: .
    networks:
      - frontend
      - backend

  # The database is ONLY on the backend network.
  # Nginx and external traffic can NEVER reach it directly.
  database:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
  backend:
    internal: true   # No external internet access from this network at all

upstream app_servers {
  # "web" is resolved by Docker's internal DNS to the web container's IP
  server web:3000;
}

server {
  listen 80;
  server_name example.com;

  # Serve static assets directly — never hits the app container
  location /static/ {
    root /var/www;
    expires 30d;
  }

  # Proxy all other requests to the Node.js app
  location / {
    proxy_pass http://app_servers;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

name: Build, Test & Deploy

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      # 1. Check out the repository code
      - name: Checkout code
        uses: actions/checkout@v4

      # 2. Log in to Docker Hub using repository secrets
      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      # 3. Build the Docker image, tagged with the git commit SHA
      - name: Build image
        run: |
          docker build -t myuser/myapp:${{ github.sha }} .
          docker tag myuser/myapp:${{ github.sha }} myuser/myapp:latest

      # 4. Run the test suite inside the freshly built image
      - name: Run tests
        run: docker run --rm myuser/myapp:${{ github.sha }} npm test

      # 5. Scan for vulnerabilities (fail on critical CVEs)
      - name: Scan for vulnerabilities
        uses: docker/scout-action@v1
        with:
          command: cves
          image: myuser/myapp:${{ github.sha }}
          exit-code: true          # fail the build on critical CVEs
          only-severities: critical

      # 6. Only push to registry if on the main branch
      - name: Push to Docker Hub
        if: github.ref == 'refs/heads/main'
        run: |
          docker push myuser/myapp:${{ github.sha }}
          docker push myuser/myapp:latest

# Stream logs from a container (like tail -f)
docker logs -f my-container

# Show last 100 lines only
docker logs --tail 100 my-container

# Show logs with timestamps
docker logs -f --timestamps my-container

# Show only logs since a specific time
docker logs --since 2024-01-15T10:00:00 my-container

# In Compose: stream logs from ALL services combined
docker compose logs -f

# Stream only the web service logs
docker compose logs -f web

services:

  # Prometheus: scrapes metrics from your app and stores them
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus

  # Loki: log aggregation (like Elasticsearch but lightweight)
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"

  # Grafana: dashboard UI — connects to both Prometheus and Loki
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana

volumes:
  prometheus-data:
  grafana-data:

# Initialize a new Swarm on this machine (becomes a manager node)
docker swarm init

# Output includes a join token for worker nodes, e.g.:
# docker swarm join --token SWMTKN-1-abc123... 192.168.1.10:2377

# On a different machine, join as a worker node:
docker swarm join --token SWMTKN-1-abc123... 192.168.1.10:2377

# See all nodes in the swarm
docker node ls

# Deploy a stack (Swarm uses the same docker-compose.yml format!)
docker stack deploy -c docker-compose.yml myapp

# List all running services across the cluster
docker service ls

# Scale a service to 5 replicas (Swarm distributes them across nodes)
docker service scale myapp_web=5

# View which nodes are running which replicas
docker service ps myapp_web

# Rolling update: deploy a new image version with zero downtime
docker service update \
  --image myapp:v2.0 \
  --update-parallelism 2 \    # update 2 replicas at a time
  --update-delay 10s \         # wait 10s between batches
  myapp_web

# Create a secret from a file
echo "supersecretpassword" | docker secret create db_password -

# Create from a file on disk
docker secret create ssl_cert ./certs/server.crt

# In docker-compose.yml (Swarm mode):
# services:
#   web:
#     secrets:
#       - db_password
# secrets:
#   db_password:
#     external: true   ← already created with docker secret create
#
# Inside the container, the secret is available at:
# /run/secrets/db_password
# Read it in your app: open("/run/secrets/db_password").read()

# ❌ WRONG — Shell form of CMD. The shell is PID 1, not node.
# SIGTERM goes to the shell and is ignored. Node gets SIGKILL rudely.
CMD node server.js

# ✅ CORRECT — Exec form (JSON array). node IS PID 1.
# SIGTERM goes directly to node, which handles it gracefully.
CMD ["node", "server.js"]

# If you need a startup script, use exec to replace the shell:
ENTRYPOINT ["./entrypoint.sh"]
# Inside entrypoint.sh, the last line should be:
# exec "$@"   ← this replaces the shell with your app process

# Give containers more time to shut down gracefully (default: 10s)
# In docker-compose.yml:
# services:
#   web:
#     stop_grace_period: 30s

services:
  web:
    image: myapp:prod
    restart: unless-stopped   # Restart on crash, respect manual stops

  database:
    image: postgres:16
    restart: unless-stopped

  migration-job:
    image: myapp:prod
    command: python manage.py migrate
    restart: on-failure      # Retry if migrations fail, but stop when done

# ❌ Floating tag — what does "latest" mean in 6 months?
FROM node:latest

# ❌ Better but still mutable — node:20-alpine can be updated
FROM node:20-alpine

# ✅ Production-grade — pinned to an exact immutable digest
# This exact content will always produce this exact hash
FROM node:20-alpine@sha256:a7ab5e2f9a12c6ba01f1c03f92f7cdb5e39d3e5c3f6c7e3b4f1234567890abcd

# Get the digest for any image:
docker inspect --format='{{index .RepoDigests 0}}' node:20-alpine