Docker for ML

This cover frames the whole post around the single sentence that haunts every ML team: 'it works on my machine.' The hook is deliberately concrete because the pain is universal — a model that trains fine on a laptop and then fails on a server, a teammate who can't reproduce your environment, a notebook that breaks after a library update.

The goal of post one is orientation. Before we argue why ML specifically needs Docker, or how to build an image, you need a clear picture of the three core objects — image, container, Dockerfile — and the one idea behind them: ship the environment itself, not instructions for recreating it.

These three terms get conflated constantly, so it's worth nailing them down. A Dockerfile is a plain text recipe: an ordered list of build instructions like 'start from this base, install these packages, copy this code.' An image is what you get when you build that recipe — a frozen, read-only snapshot of a complete filesystem plus metadata about how to run it. A container is an image that is actually running, as an isolated process on a host.

The relationship is one-to-many: you build an image once and can run any number of containers from it, each isolated from the others. This is the foundation of reproducibility — because the image is immutable, every container started from it begins in exactly the same state, on any machine that can run Docker.

The comparison clears up the most common confusion for newcomers: how a container differs from a virtual machine. A VM virtualizes hardware and boots a full guest operating system, which is why it's measured in gigabytes and takes tens of seconds to start, but also why its isolation is very strong.

A container does far less. It shares the host's kernel and isolates only a process and its filesystem view, using kernel features like namespaces and cgroups. That's why an image layer is megabytes rather than gigabytes and a container starts in milliseconds. The tradeoff is that containers offer process-level isolation rather than hardware-level isolation. For ML — where you want many fast, lightweight, reproducible environments — the container model is almost always the right fit.

Reproducibility is the entire reason Docker matters for ML, so this slide pins down what the word actually means here. It means that the same image yields byte-for-byte the same environment everywhere: the same Python interpreter, the same pinned library versions, the same system packages, the same CUDA runtime.

The practical payoff is that your training run, your teammate's run, and the production server all execute against one shared, frozen environment. When the environment is identical, an entire category of bugs — 'it worked in the notebook but not in prod' — simply disappears, because there is no longer a difference between the two environments to cause it. Pinning is what makes this real; an unpinned image is reproducible in name only.

The stack diagram shows the layered filesystem that makes images efficient. At the bottom sits the base image (here python:3.11-slim). On top of it, a layer for system packages installed via apt. On top of that, the pip-install layer with torch, numpy, and friends. At the very top, a thin layer with your own code and model.

The key visual is that the most volatile content — your code — sits at the top as a thin layer, while the heavy, stable content sits below. This ordering isn't cosmetic; as the next slide explains, it's exactly what lets the build cache reuse the expensive lower layers while only rebuilding the cheap top one when your code changes.

This slide introduces the property that makes Docker fast and economical: layers are cached and shared. Each instruction in a Dockerfile produces one layer, and Docker stores each layer keyed by its inputs. On a rebuild, it reuses every layer up to the first one whose inputs changed, and only re-runs from there.

Layers are also shared across images on the same machine. If three different images all build on python:3.11-slim, that base is stored exactly once and referenced by all three. The combined effect is that well-ordered Dockerfiles produce fast rebuilds and disk-efficient storage — and badly ordered ones throw that away, which is the failure mode the final post returns to.

This is the smallest Dockerfile that does something useful, and it shows the canonical shape every ML image follows. FROM picks a base. WORKDIR sets the working directory. COPY requirements.txt followed by RUN pip install puts dependencies in their own cached layer. COPY . . brings in the code last. CMD declares the default command.

The ordering here is doing real work even in this minimal example: requirements are copied and installed before the code, so editing your script doesn't trigger a full dependency reinstall. Keeping the first example this small lets a reader see that there's no magic — a usable ML image is six lines — before later posts layer on GPUs, multi-stage builds, and serving.

The pipeline diagram places Docker in the actual arc of an ML workflow. You start with code plus dependencies described by a Dockerfile. You build that into an image once. You then run that identical image anywhere — your laptop for a quick check, a cloud GPU box for the real run. Finally the same image serves predictions or runs training, in the same environment it was built in.

The point of the diagram is continuity: the artifact that flows through every stage is one image. There's no re-derivation of the environment at each hop, which is exactly what eliminates environment drift between development, training, and production.

The tips slide condenses post one into a portable mental model. A Dockerfile is the recipe and the image is the built dish; the container is that dish actually being served. One image runs identically everywhere. Layers are cached and shared, which is why builds are fast. And pinning versions is what makes the whole thing genuinely reproducible.

If a reader remembers only these five lines, they have the working intuition needed to read a Dockerfile, reason about why a build is slow, and follow the deeper material in the posts that follow.

The closing mistake targets the most common conceptual error: treating a container like a small virtual machine. People ssh into a running container, install packages by hand, tweak files, and expect those changes to persist — then they're surprised when the next container starts fresh.

The correction is to internalize that containers are ephemeral and rebuilt from the Dockerfile. The writable layer a container gets is throwaway; anything you want to keep belongs in the Dockerfile (so it's baked into the image) or in a mounted volume (so it lives outside the container). Once you stop editing containers live and start editing the recipe, Docker's reproducibility guarantees actually hold — which is the entire reason you reached for it.

The CTA points forward to post two, which shifts from 'what it is' to 'why it matters for ML specifically' — dependency hell, the CUDA and driver matching problem, and reproducible training you can trust months later. The teaser sets up that these aren't generic software concerns but acute, money-losing problems in machine learning.