Exercises — Containerization with Docker

• (a) Dockerfile ↔ (iii) build recipe.
• (b) image ↔ (ii) frozen read-only template.
• (c) container ↔ (i) running isolated process.

Analogy anchor: recipe → cake mould → the cake you actually eat.

The pattern is -p host:container. So 8080 = host (your machine), 8000 = container (inside). Traffic hitting localhost:8080 is forwarded to port 8000 inside the container. Left is always the outside; right is always the inside.

False. EXPOSE is metadata / documentation only — it records the port the app intends to use. Actual publishing happens with -p host:container at docker run. Without -p, nothing outside can reach the app.

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Why this order? Copy requirements.txt alone before installing so the expensive pip install layer is cached and only re-runs when dependencies change. Copy the full source (COPY . .) last, because source changes every commit — putting it last keeps $k$ (the first changed layer) as low down the file as possible.

docker run -p 5000:8000 myapp:1.0

-p host:container → host 5000 maps to container 8000. Now http://localhost:5000 forwards into the container's port 8000.

docker run -v ./data:/app/data myapp:1.0

The -v host:container flag mounts a volume. A container's own writable layer is ephemeral (destroyed on removal), so anything that must persist has to live in a mounted volume on the host.

The first changed layer is $k=4$. Layers 1–3 are cache hits (cost 0). Sum from $k=4$ to $n=5$: $C_{\text{rebuild}}=c_4+c_5=3+1=4\text{ seconds}.$ The big $c_2=90$ (pip install) is above $k$, so it is skipped entirely. Good ordering paid off.

Now the first changed layer is $k=2$. Sum from $2$ to $5$: $C_{\text{rebuild}}=c_2+c_3+c_4+c_5=90+1+3+1=95\text{ seconds.}$ Because the pip-install layer sits below the code copy, a code edit invalidates it too. Same edit, 95 s vs 4 s — a $\approx 23.75\times$ slowdown purely from ordering.

Layers are content-addressed by hash, so the shared 200 MB base is stored once, not five times.

• Shared base stored once: $200$ MB.
• Five unique app layers: $5\times 50=250$ MB.
• Total actual: $200+250=450$ MB.
• Naive assumption ($5\times 250$): $1250$ MB.
• Saved: $1250-450=800$ MB. Sharing turns "5 copies of the base" into "1 copy," which is why a common base image is so cheap across many services.

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
ENTRYPOINT ["uvicorn", "app:app", "--host", "0.0.0.0"]
CMD ["--port", "8000"]

Why the ENTRYPOINT + CMD split? ENTRYPOINT fixes the executable (uvicorn app:app --host 0.0.0.0), while CMD supplies default arguments (--port 8000) that are replaced when you pass args at run time. So docker run img --port 9000 swaps the port without editing the image — the container behaves like a real CLI tool. Requirements are copied and installed before the source so the pip layer stays cached.

1. Switch to python:3.11-slim (or distroless / multi-stage). Fixes the "use the full image to be safe" trap: the full base ships ~1 GB of build tools you never run in production — larger, slower to pull, bigger attack surface.
2. Add --no-cache-dir to pip install and copy only what you need. Fixes bloated layers caused by pip's download cache being baked into the image. Both keep the shipped runtime image minimal. (Multi-stage builds go further: compile in a fat builder stage, copy only artifacts into a slim final stage.)

Cause: the model was written into the container's ephemeral writable layer, which is discarded when the container is removed. Each fresh docker run starts a brand-new container from the unchanged image, so the previous run's .pkl does not exist. Fix: mount a volume so writes land on the host, not the ephemeral layer:

docker run -v ./artifacts:/app/artifacts myapp:1.0

Now best_model.pkl written to /app/artifacts persists on the host under ./artifacts and is available to every future run.

svc:a reproduces; svc:b does not.

• svc:a pins an immutable base tag and an exact library version, so rebuilding produces the same environment — same OS libs, same Python, same scikit-learn.
• svc:b uses latest (mutable — may now point to Python 3.13) and unpinned scikit-learn (may resolve to a newer, behaviour-changing release). Rebuilds are non-deterministic.
• CI/CD builds the image once and pushes an immutable-tagged artifact (git SHA) to a registry. From then on you pull that exact image instead of rebuilding, so even the original build inputs no longer matter — the frozen bytes are what deploys. That is the strongest reproducibility guarantee: ship the image, not the recipe.

Per rebuild saving: $95-4=91$ s.

• Per day ($30$ rebuilds): $30\times 91=2730$ s $=45.5$ minutes.
• Per 5-day week: $5\times 2730=13650$ s $=227.5$ minutes $\approx 3.79$ hours. Almost four hours a week reclaimed by a single line-ordering choice — the derivation from $C_{\text{rebuild}}={\sum }_{i=k}^n{c}_i$ turned into real payroll time.

1. In -p 3000:8000, which is the container port?
2. Where must layers that change every commit sit — top or bottom of the Dockerfile? Why?
3. If layer 3 of 6 changes, which layers rebuild?
4. Why does latest break reproducibility?
5. What survives container deletion?

Answers: 1) 8000 (right side = inside). 2) Bottom, to keep $k$ low so fewer layers rebuild. 3) Layers 3, 4, 5, 6 — from $k$ down to $n$. 4) It's a mutable tag; it can point to a different image later. 5) Only data on a mounted volume.