Docker: a container is a lie told by the kernel.

A virtual machine virtualizes hardware and boots its own kernel — heavyweight by construction. A container virtualizes nothing. It's a normal Linux process (or process tree) that the kernel systematically deceives via two mechanisms:

That's why containers start in milliseconds (nothing boots — a process forks), share the host's memory efficiently, and can be packed by the hundred onto one box. It's also why Linux containers need a VM shim on Mac/Windows — the lies are Linux-kernel lies. Docker's real invention wasn't the container; the kernel had the pieces. It was the packaging — which brings us to images.

An image is the filesystem the lie will present — built as a stack of read-only layers, one per Dockerfile instruction, each recording only the changes it made. Layers are content-addressed (Git vibes, deliberately): ten images built on the same Ubuntu base share those bytes once, on disk and in the registry. When a container runs, a thin writable layer goes on top; the image below stays immutable, which is why a container is disposable by design — kill it and the writable layer is all that dies.

The classic sins: bloated images carrying compilers into production, root processes, latest-tag roulette. The fixes are few and mechanical:

Containers forget by design — the writable layer dies with them. That amnesia is a feature (identical fresh state every run) until you're running a database. The escape hatches: volumes (Docker-managed directories mounted into the container — survive restarts, the production answer) and bind mounts (a host directory mapped straight in — the dev-loop answer, your editor writing into the running container). The discipline is knowing which data is cattle (rebuildable — leave it in the container) and which is sacred (the database files — volume, backed up).

Each container gets its own network namespace — its own localhost, which is the #1 beginner trap: localhost inside a container is the container, not your machine. Containers on the same user-defined bridge network reach each other by name (Docker runs the DNS: db:5432 just works); the outside world reaches a container only through explicitly published ports (-p 8080:80 — host:container). That's 90% of Docker networking: name-based reach within a network, port-mapping at the edge, and nothing visible unless you published it.

Real apps are several containers — API, database, cache, worker. Compose is the one-machine orchestrator: a YAML file declaring services, networks and volumes, brought up with one command, networked by name automatically. It is the standard dev environment and a perfectly honest small-deployment tool.

What Compose doesn't do is fleet: many machines, self-healing, rolling deploys, autoscaling. That's Kubernetes — same containers, a much bigger brain around them. The pipeline in practice: Dockerfile → image → registry → Compose (dev) → Kubernetes (prod), with the image as the invariant artifact moving through it. Master the image and the rest is configuration.