Docker for ML

First, watch the problem happen#

Before the Dockerfile, here is the failure it prevents. Train a model on one version of scikit-learn and load it on another.

pip install scikit-learn pandas joblib

import joblib
import numpy as np
import pandas as pd
import sklearn
from sklearn.linear_model import LogisticRegression

rng = np.random.RandomState(0)
cols = ["income", "years", "age"]
X = pd.DataFrame(rng.normal(size=(200, 3)), columns=cols)
y = (X["income"] + 0.8 * X["years"] - 0.5 * X["age"]
     + rng.normal(0, 0.7, 200) > 0).astype(int)

model = LogisticRegression(max_iter=1000).fit(X, y)
joblib.dump(model, "model.joblib")
print("saved model.joblib, trained with scikit-learn", sklearn.__version__)

saved model.joblib, trained with scikit-learn 1.7.2

Your version number will differ if you installed a different scikit-learn. That difference is the whole point of this section.

import sys

import joblib
import pandas as pd
import sklearn

model = joblib.load("model.joblib")

print("python       ", ".".join(map(str, sys.version_info[:2])))
print("scikit-learn ", sklearn.__version__)
print("expects      ", list(model.feature_names_in_))

applicants = pd.DataFrame([
    {"income": 1.5, "years": 0.9, "age": -0.4},
    {"income": -1.2, "years": -0.5, "age": 1.1},
])
print("predictions  ", model.predict(applicants))

Run python train.py and then python predict.py, and everything is calm:

python        3.10
scikit-learn  1.7.2
expects       ['income', 'years', 'age']
predictions   [1 0]

Now load the same file in an environment with an older scikit-learn:

python -m venv oldsk
oldsk/bin/pip install "scikit-learn==1.5.2" pandas joblib   # Windows: oldsk\Scripts\pip
oldsk/bin/python predict.py

.../site-packages/sklearn/base.py:376: InconsistentVersionWarning: Trying to unpickle estimator LogisticRegression from version 1.7.2 when using version 1.5.2. This might lead to breaking code or invalid results. Use at your own risk. For more info please refer to:
https://scikit-learn.org/stable/model_persistence.html#security-maintainability-limitations
  warnings.warn(
python        3.10
scikit-learn  1.5.2
expects       ['income', 'years', 'age']
predictions   [1 0]

Look closely at what happened. It warned. It did not stop. And this time the predictions were identical.

That is the worst possible outcome, and it is why this lesson exists. A warning that is usually harmless trains you to ignore it.

For a LogisticRegression, which stores two small arrays, a version gap is usually survivable. For a tree ensemble it is not. If the internal layout changed between releases, the same warning precedes wrong numbers or a crash. By then it is in production.

Now the Dockerfile that removes the question#

joblib==1.5.3
numpy==2.2.6
pandas==2.2.3
scikit-learn==1.7.2

Use the versions from your own pip list, not these. The point is that they are pinned, not which numbers they are.

FROM python:3.11-slim

# Print appears immediately instead of sitting in a buffer. Matters the first
# time you are staring at an empty log wondering if anything is running.
ENV PYTHONUNBUFFERED=1

WORKDIR /app

# requirements.txt is copied on its own, before the code. Docker caches each
# step, so editing predict.py later does not reinstall every library.
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY model.joblib predict.py ./

# Containers run as root unless you say otherwise. Two lines to fix that.
RUN useradd --create-home appuser
USER appuser

CMD ["python", "predict.py"]

python train.py               # produces model.joblib on your machine
docker build -t loan-model .
docker run --rm loan-model

python        3.11
scikit-learn  1.7.2
expects       ['income', 'years', 'age']
predictions   [1 0]

Note the first line. The container is running Python 3.11 even though the model was trained on 3.10. The libraries are pinned, so the load is clean and there is no warning.

No output block for docker build. Its log is a stream of layer ids, download sizes and timings. Those differ on every machine and every day. A made-up one would teach you to expect something you will never see.

What is true: the first build downloads a few hundred megabytes. The finished image lands somewhere around half a gigabyte. Every later build reuses the cache and finishes in seconds. Check the real size for yourself with docker images.

The four lines that are doing real work#

FROM python:3.11-slim — the base. -slim drops compilers and documentation, saving several hundred megabytes. Use -slim unless a package needs to compile from source, in which case you want a multi-stage build rather than the fat base.

COPY requirements.txt ./ before COPY predict.py — this is the layer-caching trick, and it is the difference between a two-second rebuild and a four-minute one. Docker caches each instruction. Any change invalidates that step and everything after it. Your code changes fifty times a day; your requirements change monthly. Put the slow, stable step first.

pip install --no-cache-dir — pip keeps downloaded wheels in a cache directory. Inside an image that cache is dead weight baked into a layer forever.

USER appuser — a container that runs as root, mounted onto a host directory, can write to that directory as root. This line takes ten seconds and closes that door.

Common mistakes#

Unpinned requirements. scikit-learn with no version means your image is a different image every time it builds. You then have a Dockerfile in git that cannot rebuild what is running in production. Pin every direct dependency, and for real deployments pin transitive ones too with pip freeze > requirements.lock.txt.

Copying the whole directory. COPY . . sweeps in your .git folder, your virtual environment, your notebook checkpoints and your dataset. Write a .dockerignore on day one:

.git
.venv
__pycache__
*.ipynb_checkpoints
data/
mlruns/
mlflow.db

Training inside the image. The build then takes hours, cannot use a GPU on most build systems, and produces a different model every rebuild. Train outside, save the artefact, copy it in.

Baking secrets in with ENV. Anything set in the Dockerfile is readable by anyone who pulls the image, including in deleted layers. Pass credentials at run time with -e or a mounted secret.

Assuming your laptop's architecture matches the server's. An image built on an Apple Silicon Mac is arm64; most cloud servers are amd64. Use docker build --platform linux/amd64 when they differ, and expect it to be slower.

Expecting Docker to fix a stale model. It freezes the environment, not the world. Freshness is monitoring, not packaging.

Try it yourself#

Change one digit in requirements.txt — set scikit-learn==1.5.2 — then rebuild and run.

The InconsistentVersionWarning from the top of this page appears inside the container. That is the useful lesson: Docker did not make the version problem disappear. It made it a line in a file you can read, review and change on purpose.

What to learn next#

• Model serving — putting an API in front of the container you built.
• CI/CD for machine learning — building this image automatically on every commit.
• Monitoring and model drift — the failure a frozen environment cannot prevent.