Creates a distroless container image with up-to-date python installed
No latest tag is offered. The intent is to be intentional (!) in your choice of version and when to upgrade.
Usage examples can be found in the tests/ directory. These are also described in EXAMPLES.md.
In general, you're going to want this:
FROM al3xos/python-distroless:3.13-debian12A debug image also exists:
docker run --rm -it --entrypoint=sh al3xos/python-distroless:3.13-debian12-debugThere are variants for Python versions 3.11, 3.12 and Python 3.13, all based on Debian 12. They are built from the python:3.x-slim-bookworm image base.
Both linux/amd64 and linux/arm64 variants are pushed. Your docker environment should pull down the one that matches your platform (they are built using docker buildx)
For convenience, the builder image used to create the above is also published. This is not in general going to be useful in running python apps, but can be a convenient way to get a top layer that is python:3.13-slim-bookworm but with a non-root user and virtualenv/pipenv/poetry pre-installed - fewer stuff for you to sort in your Dockerfile! (Equivalent tags for 3.11 and 3.12 also exist).
To use it:
FROM al3xos/python-builder:3.13-debian12This repo now only publishes Python 3.11, 3.12 and 3.13 images based on Debian 12 (bookworm). Whilst images for 3.9 and 3.10 do exist, they were last published on 24/11/2023 and will miss important security fixes - maintaining the tests for Bullseye was getting troublesome.
Python and OS version are set in .gitlab-ci.yml. This repo originates at https://gitlab.com/alexos-dev/distroless-python but is mirrored to Github https://github.com/alexdmoss/distroless-python for convenience in sharing. Perhaps I'll convert to use Github actions at some point 🤷♂️
- Variants based on Debian (e.g.
python:*-slim-bullseye) often have a number of vulnerabilities in them. Debian take their time responding and deal with many, and whilst this is quite often for very justifiable reasons, it is pretty toilsome work to reason about the risk and patch or suppress as needed. - Alpine would be my normal go-to here but that experience with Python is grim. I believe it all stems from its use of
muslrather thanglibcas its standard C library. Python wheels exist for the latter (so builds are much faster) and the two are not perfectly interoperable (i.e. there are potentially subtle bugs or performance differences). This excellent blog post elaborates on this. - The Google Distroless image for Python is marked as experimental and has been for a while, and tied to what Debian ships with - i.e. an old copy of python and dependent libraries. In other words it does not really solve for the problem statement in (1), and comes with several of its own.
Following issues copying the Bazel-based approach used by Google's distroless repo itself, I switched approach to a technique I understood better - multi-layer docker images. I took the distroless C image as a base and then used an earlier docker layer to bring in my choice of Python + its dependencies in.
These images are based on Google's distroless images, which are distributed under the Apache-2.0 license. This repo therefore uses the same.
