Docker & Deployment

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Common follow-ups: Why does the order of COPY instructions in a Dockerfile matter for build speed?;What's the difference between the 'node' and 'node:alpine' base images in terms of size and compatibility?

FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

Common follow-ups: Why does a smaller final image matter for deployment speed and security?;How do you decide what to copy from the builder stage versus rebuild from scratch in the final stage?

process.on('SIGTERM', () => {
  console.log('SIGTERM received, shutting down gracefully');
  server.close(() => {
    db.disconnect().then(() => process.exit(0));
  });
  setTimeout(() => process.exit(1), 10000); // force exit if graceful shutdown hangs
});

Common follow-ups: Why might Node.js not receive SIGTERM correctly when run as PID 1 inside certain container configurations, and how does an init process like tini solve that?;What's an appropriate grace period to configure before Kubernetes escalates to SIGKILL?

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

# Runs 'node server.js' by default
# docker run myapp                actually runs: node server.js
# docker run myapp worker.js       overrides CMD: node worker.js

Common follow-ups: What happens if both ENTRYPOINT and CMD are specified using the shell form rather than the exec (array) form?;Why is the exec (array) form generally preferred for both instructions?

FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --chown=appuser:appgroup . .
USER appuser
CMD ["node", "server.js"]

Common follow-ups: What specific additional Docker or Kubernetes security features (like read-only root filesystems) complement running as non-root?;Does official Node.js Docker images already include a pre-configured non-root user option?

version: '3.8'
services:
  app:
    build: .
    ports: ['3000:3000']
    environment: { DATABASE_URL: postgres://db:5432/app }
  db:
    image: postgres:16
    ports: ['5432:5432']
  redis:
    image: redis:7

Common follow-ups: How does Compose's internal networking let the app container reach the db container by service name?;What's the difference between using Docker Compose for local development versus production orchestration?

# docker-compose.yml
services:
  app:
    build: .
    env_file: .env.production

# Or at build/run time
docker run --env-file .env.production myapp

Common follow-ups: Why is baking a .env file directly into a Docker image considered a security anti-pattern?;How does this approach interact with a proper secrets manager for genuinely sensitive values in production?

# Good ordering: dependencies before source code
COPY package*.json ./
RUN npm ci
COPY . .          # only this layer invalidates on a normal code change

# Bad ordering: any code change invalidates the npm ci cache too
COPY . .
RUN npm ci

Common follow-ups: What specifically invalidates a Docker layer cache, causing that layer and everything after it to rebuild?;How does BuildKit's cache mount feature further improve on this for the npm/yarn cache directory itself?

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD node healthcheck.js || exit 1

// healthcheck.js: makes a request to the app's own /health endpoint
// and exits with a non-zero code if it doesn't respond successfully

Common follow-ups: How does a Dockerfile-level HEALTHCHECK relate to and differ from Kubernetes's own separate liveness/readiness probes?;What happens to a container marked 'unhealthy' by Docker if nothing is configured to act on that status?

# PaaS deployment: often just a git push or a single CLI command
git push heroku main

# Kubernetes: requires defining and managing much more infrastructure yourself
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f hpa.yaml

Common follow-ups: At what specific scale or complexity threshold does the operational overhead of Kubernetes typically become worth it over a PaaS?;What middle-ground options (like AWS ECS/Fargate) exist between a full PaaS and self-managed Kubernetes?