Dockerizing Python Apps

Slim Base and a Virtualenv

The venv travels with the image so the app never depends on system site-packages:

FROM python:3.12-slim AS build
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.12-slim
COPY --from=build /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app
COPY . .
CMD ["python", "-m", "app"]

Creating the venv in a builder stage keeps compilers and pip's download cache out of the final image, while the copied /opt/venv is a self-contained, relocatable environment.

Layer Order and Runtime Hygiene

Dependencies change less often than source — encode that in the Dockerfile: COPY requirements.txt before COPY . ., and add a requirements hash if you want stricter cache keys. Runtime flags worth setting by default:

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1 \
    PIP_NO_CACHE_DIR=1

PYTHONUNBUFFERED streams prints straight to stdout, so docker logs shows progress live instead of losing it in a buffer. Run as non-root with useradd and USER app, and use python -m package as CMD so relative imports resolve with package context.

Pitfalls and Interview Angles

Native extensions. Packages like psycopg2 (source build) need gcc and libpq-dev; install them in the builder stage and copy only the compiled venv — never apt-get build tools into runtime.

Requirements drift. Pin versions (fastapi==0.115.0) or, better, a compiled lock file; an unpinned requirements.txt makes yesterday's image unreproducible.

Dev servers in production. uvicorn --reload watches files that do not exist in the final image; run without reload and let the platform restart on failure.

Interview: explain the two-stage layout, why -m beats a script path, and where system libraries fit when wheels are not available.