Docker

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: ...

You run a Docker command and get this: G P d o o i t s a t l p e " u r h n m t i i t x s p s : i / a n % r 2 / d F r e v u n a n i r / e % d d 2 o F c w r k h u e i n r l % . e 2 s F o t d c r o k y c : i k n e c g r o . n t s n o o e c c c k t o / : n v n 1 p e . e c 2 r t 4 m / i t c s o o s n i t t o h a n e i n d D e e o r n c s i k / e e c d r r e d a a t e e m " o : n s o c k e t a t u n i x : / / / v a r / r u n / d o c k e r . s o c k : This happens because Docker runs as root by default, and your user doesn’t have permission to access the Docker socket. Here’s how to fix it properly. ...

You’ve set DATABASE_URL in your .env file. You’ve exported it in your shell. But your application still can’t find it. Sound familiar? Environment variable issues are one of the most common — and frustrating — debugging sessions. Here’s a systematic guide to finding and fixing the problem. The Quick Checklist Before diving deep, check these common culprits: Did you restart your application? Environment variables are read at process start Are you in the right shell session? Variables exported in one terminal don’t exist in another Is your .env file in the right directory? Most libraries look in the current working directory Did you spell it correctly? DATABASE_URL vs DATABSE_URL happens more than you’d think Python: The os.environ Mystery Problem: KeyError When Accessing Variables 1 2 import os database_url = os.environ['DATABASE_URL'] # KeyError! Fix 1: Check if the variable exists first ...

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: ...

Your container builds fine, starts fine, then fails with Could not resolve host or Temporary failure in name resolution. Here’s how to fix it. Quick Diagnosis First, confirm it’s actually DNS and not a network issue: 1 2 3 4 5 6 7 8 # Get a shell in the container docker exec -it <container_name> sh # Test DNS specifically nslookup google.com # or cat /etc/resolv.conf ping 8.8.8.8 # If this works but nslookup fails, it's DNS If ping 8.8.8.8 works but nslookup google.com fails, you have a DNS problem. If both fail, it’s a broader network issue. ...

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. ...