docker¶

Overview¶

Docker provides a way to package, ship and run applications in containers. Containers are lightweight and portable: they guarantee that the application will always run the same way regardless of the environment it is running in. In the context of Python applications, Docker provides an easy way to ensure that the application will always run with the correct dependencies and environment.

Cookbook¶

Recommendation for setting DEBIAN_FRONTEND¶

Setting DEBIAN_FRONTEND to noninteractive via ENV is not recommended. This is because the environment variable persists after the build, e.g. when running docker exec -it … bash. The setting would not make sense here.

Two possible ways to set DEBIAN_FRONTEND are:

Setting it via ARG, which is only available during build:

ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get -qq install {your-package}
When required, setting it on-the-fly.

RUN apt-get update && \
DEBIAN_FRONTEND=noninteractive apt-get -qq install {your-package}

See: https://bobcares.com/blog/debian_frontendnoninteractive-docker/

Using Alpine for Python projects is not recommended¶

Using Alpine for Python projects is not recommended. Instead, use the slim Debian-based images. Alpine is better suited for languages like Go, where you build a static binary in one Docker image stage and then copy it to a simple Alpine image.

For Python, Alpine doesn't use the standard tooling for building Python extensions, so when installing packages, pip often can't find precompiled wheels for Alpine. This means you'll need to install extra tooling and build dependencies, resulting in an image size comparable to, or even larger than, a standard Debian-based Python image.

Using slim Debian-based images is a better option for Python projects. They are smaller and take less time and resources to build, resulting in a lower carbon footprint.

See: https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker