Alpine as base image for docker

[marchrius]

Proposal

Hi all,
is there a reason why debian-slim base image was used rather than python-alpine?

I'm building images with python-alpine as base image (python:3.13.1-alpine) without installing the deb but building code inside the container and creating image from the result container.

At the moment of writing with python:3.13.1-alpine and globaleaks v5.0.79 we have and image of ~100 MB compared to ~346 MB for the same version but with debian-slim.

[evilaliv3]

Thank you for the question @marchrius

Regarding the choice to use debian-slim is that considering the team and community resources current focus of the research is on one system (Debian) with the extention to ubuntu just because very very similar.

regarding The bigger size of the image that you obtain i guess it might be related to the version of the requirements.txt that you are using and specifically on the fersion of python3-fpdf and more specifically its dependency python3-fonttools. python3-fonttools in its latest versions uses scipy that add the weight that you have notice.

You can compare here debian-bookworm was 176mb, while debian trixie is 346mb and the difference is caused by python3-fonttools+scipy that we use to generate reports in PDF instead of TXT: https://hub.docker.com/repository/registry-1.docker.io/globaleaks/globaleaks/tags

[marchrius]

Thanks @evilaliv3 for answering me.

I'm building internal docker image with python-alpine using requirements.txt.trixie so I'm using the same library. Is there some conditional clause that cause the non-installation of the functionalities?

Just to be sure, if I exec pip list into my container I have these components installed

/usr/share/globaleaks/backend # pip list
Package            Version
------------------ --------
acme               4.0.0
attrs              25.3.0
Automat            25.4.16
Brotli             1.1.0
certifi            2025.8.3
cffi               1.17.1
charset-normalizer 3.4.3
constantly         23.10.4
cryptography       43.0.0
defusedxml         0.7.1
fonttools          4.59.2
fpdf2              2.8.3
greenlet           3.2.4
h2                 4.2.0
hpack              4.1.0
hyperframe         6.1.0
hyperlink          21.0.0
idna               3.10
incremental        24.7.2
josepy             2.0.0
legacy-cgi         2.6.3
pillow             11.3.0
pip                24.3.1
priority           2.0.0
pyasn1             0.6.1
pyasn1_modules     0.4.2
pycparser          2.22
PyNaCl             1.5.0
pyOpenSSL          25.0.0
pyotp              2.9.0
pyRFC3339          2.1.0
python-gnupg       0.5.4
pytz               2025.2
requests           2.32.5
service-identity   24.2.0
setuptools         80.9.0
six                1.17.0
SQLAlchemy         2.0.40
Twisted            24.11.0
txtorcon           24.8.0
typing_extensions  4.15.0
urllib3            2.5.0
zope.interface     7.2

Maybe I'm missing something.

You can compare here debian-bookworm was 176mb, while debian trixie is 346mb and the difference is caused by python3-fonttools+scipy that we use to generate reports in PDF instead of TXT

Were I can find the functionality? I want to check if all the dependencies are working as expected on my side.

These are the file created on the python-alpine base image by a test recipient with a single report in the system.

report-1.zip

report.pdf

[evilaliv3]

Thank you for the detailed question @marchrius

Let me explain the differences and the reasons why we use Debian packaging instead of PIP.

With PIP you are installing the packages and versions that we have written in the requirements (that correspond for each debian distribution to the versions included in that versions of debian), but the subdependenices are currently auto-resolved. To achieve better result you should do a full freeze and by doing that you would freeze the resolution of the packages made today.

By using Debian packaging instead of this we are doing something similar but more sophisticated:

• Installing via debian packaging for an LTS debian distributions we are installing the same set of packages but an exact set of versions known to be stable and work well between each other and tested carefully by debian in their release lifecycle;
• Given a version of one package, installing with debian we are getting that version of that package including patches of stability and security included by debian in the package, eventually backported from an up to date version.
  This means that for any of our releases we are able to guarantee full or very high reproducibility and all the additional quality assurance added by Debian that is something that is missing on a simple PIP setup.

I hope this helps and please feel free to make us other question or provide your very valuable feedback :)

[evilaliv3]

Hello @marchrius

I've a very nice update on the matter.
With @rglauco we have worked optimizing the docker image for trixie that was in fact scipy that is very big and we have found ways to use python3-munkres as compatible alternative.
This lead to a full system in less than 156MB of image.
Please not that running via PIP only you are missing to include many components (like Tor for example) and all the above comments remain valid.

[marchrius]

Hi @evilaliv3 first of all, great goal!

I've understood why the difference in image size and the decision to keep it LTS instead of using probably insecure or well tested dependencies.

Thanks for the very instructive conversation.

[evilaliv3]

Thank you @marchrius for your feedback.

Of coure, the package for alpine or more prioritarly for a centos remains interesting if supported by significant advantages and performed using the specific packaging system (apk or rpm)
I would not priritize just the size of the build by using PIP directly.

[marchrius]

I'll dig more accurately this aspect. My personal goal is to skip deb to be able to use a very minimal docker image with of course all requested functionalities like tor, pdf generation etc.