How Docker Really Works: Images, Layers & Containers

Docker exists because the environment your code runs in isn't part of your code. Your laptop, CI, and production drift apart silently until something breaks. Containers fix this by packaging the app and its environment together — and unlike virtual machines, they share the host kernel and use Linux namespaces and cgroups for isolation instead of booting a second OS.

An image is a read-only stack of layers built by docker build. A container is a running instance that adds a thin writable copy-on-write layer on top. Every Dockerfile instruction creates a cached layer, so instruction order matters enormously — copying package.json and running npm install before copying source code keeps dependency installs out of your rebuild path. Layers are also additive, which is why deleting a file later doesn't shrink the image and why secrets baked into a layer stay there permanently.

Understanding layers, volumes, and user-defined networks is the difference between 15-second builds and 4-minute ones, and between data that persists and data you lose on docker rm.