You write code. It works beautifully on your laptop. You send it to a teammate — or push it to a server. It immediately explodes. 💥

• Python 3.10 on dev, Python 3.8 on server
• Works on Mac, broken on Windows
• Library version mismatch
• Missing env variables on prod
• "Did you install the correct Node version?"

Estimated developer time lost to environment issues: a lot. A painful lot.

A Virtual Machine emulates a complete physical computer — including its own full OS — running on top of a hypervisor.

• Each VM has its own full Guest OS (2–20 GB overhead per VM)
• Hypervisor manages hardware sharing
• Complete isolation — like separate physical computers
• Boot time: 1–5 minutes
• Examples: VMware, VirtualBox, Hyper-V, AWS EC2

Each VM = full OS copy. That's a lot of redundant weight.

A container packages your app with its dependencies — but shares the host OS kernel. No full OS per container. That's the key difference.

• No Guest OS — just app + bins/libs (MBs not GBs)
• Uses Linux namespaces for isolation (own filesystem, network, processes)
• Uses cgroups to limit CPU/memory
• Starts in milliseconds to seconds
• Same container runs on any Linux machine — identical behaviour

No Guest OS layer. That entire row is gone. 🎉

💡 In reality: containers often run inside VMs.
AWS EC2 = VM. Your Docker containers run on top of it.

Containerisation is not a Docker invention. It's built directly into the Linux kernel. Docker, Podman, containerd — they're all just wrappers around two kernel features.

Each namespace type isolates something different — you pick what to unshare:

# Isolate process IDs (PID namespace)
unshare --fork --pid --mount-proc /bin/bash

# Isolate the hostname (UTS namespace)
unshare --uts /bin/bash
hostname my-container   # host is unaffected

# Isolate the filesystem (mount namespace)
unshare --mount /bin/bash
mount --bind /tmp /mnt  # invisible outside

# Isolate the network stack (NET namespace)
unshare --net /bin/bash
# no network interfaces visible here

# Combine them all — now it's basically a container
unshare --fork --pid --mount-proc --uts --mount --net /bin/bash

Docker is an open-source platform to build, ship, and run containerised applications. Think of it as the tool that made containers easy enough for mere mortals to use.

Linux containers existed since 2008 (LXC). But they required deep kernel expertise. Docker made them accessible with a simple CLI and workflow.

How layers stack when you run a container:

A Dockerfile is a plain text file — a step-by-step recipe that tells Docker how to build your image. Docker reads it top to bottom, and each instruction creates a new layer.

• Always starts with FROM — the base image
• Each instruction = one cached layer
• Layers are reused if unchanged — fast rebuilds
• File is literally named Dockerfile (no extension)

# Start from official Python image
FROM python:3.11-slim

# Set working directory inside container
WORKDIR /app

# ← Pro tip: copy this FIRST
COPY requirements.txt .
RUN pip install -r requirements.txt

# Now copy the rest of the code
COPY . .

# Document the port (doesn't open it)
EXPOSE 5000

# What runs when container starts
CMD ["python", "app.py"]

Building & Running

Inspecting & Cleaning Up

Docker Compose lets you define your entire application stack in a single YAML file, then start everything with one command.

A typical web app needs:

# docker-compose.yml
services:

  web:
    build: .          # build from Dockerfile
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://
          db:5432/mydb
    depends_on:
      - db            # start db first
      - redis

  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - pgdata:/var/lib/postgresql

  redis:
    image: redis:7-alpine

volumes:
  pgdata:             # data persists on restart

💡 All services share a network. web can reach db by hostname "db". Docker's internal DNS does this automatically.