Docker Algorithms

A Docker image isn't one monolithic file — it's read-only layers stacked on top of each other. Each Dockerfile instruction creates one layer, and at run time a writable container layer is added on top so the whole stack looks like a single filesystem. Identical layers are shared between images and cached, which makes instruction order the thing that decides your build speed and image size.

What you need to build and what you need to run are different things. Compilers, build tools and dev dependencies are only used while making the image, yet a single-stage build leaves all of them in the final one. A multi-stage build copies just the artifact out of the builder stage and throws the rest away, taking the same app's image from over a gigabyte down to the low hundreds of megabytes.

A virtual machine boots a full guest OS on a hypervisor and isolates at the hardware level; a container shares the host kernel as-is and isolates processes with namespaces and cgroups. Removing that entire guest OS layer is what makes containers start in seconds with tiny images — at the cost of a shallower isolation boundary.

A container is a process that gets created and eventually disappears, moving between Created, Running, Paused and Exited along the way. `docker run` is really create and start combined, and `stop` sends SIGTERM first, waits, then forces SIGKILL. Knowing which command causes which transition also tells you exactly when your data goes away.

A container's writable layer lives and dies with the container, so deleting the container takes everything written inside it. A volume mounts host-side storage onto a path in the container, putting the data outside the container's lifetime — which is why the database files survive even when you replace the container entirely.

Containers on the same bridge network each get a private IP and find one another by service name alone. That network isn't visible outside the host, though, so reaching a container from outside means mapping a host port to a container port with something like `-p 8080:80`. Names on the inside, port mapping on the outside — telling those two apart is the whole point.

A registry doesn't move images whole. An image is a manifest — a list of layers — plus the layers, and push and pull transfer only the layers the other side is missing. Each layer is identified by a content hash (its digest), so uploading many images built on the same base still stores that base layer exactly once.

Real apps don't stop at one container. Bringing up web, API and database, wiring them onto a network and attaching volumes with a series of `docker run` commands is hard to reproduce. Compose declares that whole setup in one YAML file and brings it up with a single `docker compose up`, where each service name doubles as its hostname on the network.