Docker Algorithms

Typing a docker command does not make that program build a container. Docker splits into a Client that sends commands, the daemon (dockerd) on a Docker Host that actually handles images and containers, and a Registry that stores images — and the three talk over APIs. A pull is the daemon fetching an image from the registry onto the host; a run is copying that image into a live instance.

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 what you leave in the final image the thing that decides its size. A multi-stage build throws the build-only layers away wholesale, taking the same app from over a gigabyte down to a hundred-odd 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.