metals_api/Dockerfile, Line by Line

Debian with Python 3.11 and pip pre-installed. The version is pinned to 3.11 deliberately — it matches the version the project's tests run against in CI and the version the API was developed on. -slim keeps the image small while retaining glibc, so psycopg and argon2-cffi install as pre-built wheels instead of compiling from source.

Stops Python writing __pycache__ folders next to the source. In a container those cached files are pure overhead: the code never changes after the image is built, so nothing is ever saved by caching it, and the files just add weight and noise to the writable layer.

By default Python buffers its output when it isn't writing to a terminal — which is exactly the situation inside a container. Without this, log lines sit in a buffer instead of appearing, and a crash can lose the very messages explaining it. Setting it makes docker logs and Azure's log stream show output the moment it's produced.

These two variables show up in nearly every production Python Dockerfile you'll read. Now you know why.

requirements.txt is the application's own dependency list, shared with local development and CI. requirements-container.txt simply includes it and adds the one package only the container needs:

requirements-container.txt-r requirements.txt
gunicorn>=23.0,<24.0

That keeps Gunicorn out of local development environments, where Flask's built-in server is used, while guaranteeing the container and the tests agree on every other version.

The application code is the most frequently changed input, so it's copied as late as possible. Editing a route handler invalidates only this layer and the ones below it — the pip install above stays cached, and the rebuild takes a second or two instead of a minute.

requirements.txt lives at the repository root while the Dockerfile lives in metals_api/. Since COPY can't reach outside the build context, the context must be the root — hence docker build -f metals_api/Dockerfile . with the dot at the end. The root .dockerignore then trims that context back down so the rest of the repository isn't shipped to the builder.

Creating the user is chained onto the pip install with && so both land in a single layer. The explicit high --uid matters in Kubernetes-style environments that refuse to run containers whose user ID falls in the system range, and it keeps the ID stable across rebuilds rather than depending on whatever the system assigns next.

The switch happens after pip install, because installing into system site-packages needs root. Everything from that line onward — including the container's main Gunicorn process — runs as the unprivileged account. If the API were ever compromised, the attacker lands as appuser with no ability to modify the installed runtime.

This is the same protection the UI image gets for free by choosing the nginx-unprivileged base — see the next page.

The check fetches http://127.0.0.1:5000/health from inside the container, using Python's standard library so no extra tool has to be installed. That endpoint is defined in app.py and deliberately doesn't touch the database — it reports whether the HTTP server is alive, not whether every dependency is. A health check that fails when the database blips would restart a perfectly healthy API.

The same /health path is reused by Compose's depends_on gate and by Azure's healthCheckPath setting — one endpoint, three consumers.

Binding to 0.0.0.0 means “listen on every network interface in this container.” Binding to 127.0.0.1 instead would accept only connections originating inside the container, so published ports and requests from the UI container would both be refused — a classic first-container bug that looks like a networking failure but isn't.

Gunicorn's final argument is module:callable: load app.py and serve the object named app inside it — the Flask instance created by create_app(). It resolves relative to the working directory, which is why the second WORKDIR /app/metals_api exists.

Two worker processes, each able to handle a request at a time. That's a modest, deliberate number matched to the single small Azure App Service instance this project runs on; a larger machine would warrant more. Logs from both workers are pointed at standard output with -, so the container's logs are the application's logs.