Containers

You run docker run myimage or docker compose up and the container vanishes instantly. docker ps shows nothing. docker ps -a shows the container with status Exited (0) or Exited (1) seconds ago. Here’s how to figure out what’s happening and fix it. Step 1: Check the logs first Before anything else: 1 docker logs <container_id_or_name> If the container is already gone, use the container ID from docker ps -a: ...

Your pod is stuck in CrashLoopBackOff. Kubernetes keeps restarting it, each time waiting longer before trying again. Here’s how to diagnose and fix it. What CrashLoopBackOff Actually Means CrashLoopBackOff isn’t the error itself — it’s Kubernetes telling you “this container keeps crashing, so I’m backing off on restarts.” The actual problem is that your container exits with a non-zero exit code. Kubernetes notices, restarts it, it crashes again, and the backoff timer increases: 10s, 20s, 40s, up to 5 minutes. ...

You run docker run myimage and… nothing. The container starts, exits immediately, and you’re left staring at a silent terminal. Sound familiar? This is one of the most common Docker frustrations, especially for beginners. Let’s fix it. Understanding Why Containers Exit A Docker container runs as long as its main process (PID 1) is running. When that process exits, the container exits. This is by design — containers aren’t VMs that sit around waiting for something to happen. ...

Your container is restarting. Over and over. docker ps shows it’s been up for 3 seconds, then 5, then 2. You’re stuck in a loop and the logs aren’t helping. Here’s how to debug it systematically. Step 1: Check the Exit Code 1 docker inspect --format='{{.State.ExitCode}}' container_name Common exit codes: 0: Clean exit (container finished its job) 1: Application error (check your code) 137: OOMKilled (out of memory) 139: Segfault 143: SIGTERM (graceful shutdown) If you see 137, your container is being killed for using too much memory. Skip to the OOM section below. ...

Your container starts, immediately dies, restarts, dies again. The docker ps output shows “Restarting (1) 2 seconds ago” and you’re watching it cycle endlessly. Here’s how to break the loop and find the actual problem. Step 1: Check the Exit Code First, figure out how it’s dying: 1 docker inspect --format='{{.State.ExitCode}}' container_name Common exit codes: 0 — Clean exit (shouldn’t restart unless you have restart: always) 1 — Application error (check logs) 137 — Killed by OOM (out of memory) 139 — Segmentation fault 143 — SIGTERM received (graceful shutdown request) Step 2: Read the Logs (Before They Disappear) Containers in restart loops lose logs on each restart. Catch them quick: ...

Docker Compose is great for local development. Getting it production-ready requires a different mindset. Here’s what changes and why. The Development vs Production Gap Your dev docker-compose.yml probably looks like this: 1 2 3 4 5 6 7 8 9 10 version: '3.8' services: app: build: . ports: - "3000:3000" volumes: - .:/app environment: - DEBUG=true This works locally but fails in production: ...

Docker Compose isn’t just for development. With the right patterns, it’s a legitimate production deployment tool for small-to-medium workloads. Here’s how to do it without the footguns. Base Structure 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # docker-compose.yml version: "3.8" services: app: image: myapp:${VERSION:-latest} restart: unless-stopped environment: - NODE_ENV=production deploy: resources: limits: cpus: '2' memory: 1G healthcheck: test: ["CMD", "curl", "-f", "http://localhost:3000/health"] interval: 30s timeout: 10s retries: 3 start_period: 40s Key elements: ...

Containers aren’t inherently secure. They share a kernel with the host. A container escape is a host compromise. Here’s how to not be the cautionary tale. Image Security Use Minimal Base Images Every package is attack surface. Minimize it. 1 2 3 4 5 6 7 8 # Bad: Full OS with thousands of packages FROM ubuntu:22.04 # Better: Minimal OS FROM alpine:3.19 # Best: Distroless (no shell, no package manager) FROM gcr.io/distroless/static-debian12 Distroless images contain only your app and runtime dependencies. No shell means attackers can’t get a shell. ...

Your pod won’t start. The service isn’t routing. Something’s wrong but kubectl isn’t telling you what. Here’s how to actually debug Kubernetes problems. The Debugging Hierarchy Work from the outside in: Cluster level — Is the cluster healthy? Node level — Are nodes ready? Pod level — Is the pod running? Container level — Is the container healthy? Application level — Is the app working? Most problems are at levels 3-5. Start there. ...

Docker makes it easy to containerize applications. Docker makes it equally easy to create bloated, insecure, slow-to-build images. The difference is discipline. These practices come from running containers in production—where image size affects deployment speed, security vulnerabilities get exploited, and build times multiply across teams. Start With the Right Base Image Your base image choice cascades through everything else. The options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # Full OS - 900MB+ FROM ubuntu:22.04 # Slim OS - 80MB FROM debian:bookworm-slim # Minimal - 5MB FROM alpine:3.19 # Language-specific slim - varies FROM python:3.12-slim FROM node:20-alpine # Distroless - minimal runtime only FROM gcr.io/distroless/python3 General guidance: ...