The latest docker image is very large

Gramps Web
1

Hello,

I just updated my docker and it pulled among others a 963 MB image (IMAGE ID [d78ce5314e5d]) + 329 MB image (IMAGE ID [66f1dc0fc62d]) from github grampsweb latest-devel container.

latest-devel
sha256:cbb0c0eb6bc28119b05f22d08c5741d092d0329b38c9ea605f162b3400be0d35

Also the container takes more than 5GB of RAM.

Is that on purpose?

I’m wondering if it’s because of an unoptimized port for my OS (Unraid) which I downloaded through the appstore.

I would be glad, if someone could look into this. Thank you.

2

Hi,

For job reasons I won’t have time to look into this today or tomorrow, but I would be very grateful if you could investigate, e.g. look at the evolution of image size over the last couple of tags. I noticed that the devel image build started failing today and I don’t know why, or whether it’s related.

3

Hi,

So the current ghcr.io/gramps-project/grampsweb:latest image is very large, it’s around 6 GB for me (on amd64).
After checking, it turns out the image is mostly a wrapper around dmstraub/gramps-webapi:latest, which includes several 1–2 GB layers of build tools and desktop libraries (GTK, Cairo, ICU, TeX, Graphviz, etc.) left in the final runtime image.
No multi-stage build is used, and apt caches/locales are not cleaned.

I built a minimal test image using python:3.11-slim and only the runtime deps (python3-gi, libcairo2, libicu-dev, libpq-dev, etc.).
It installs gramps-webapi + gunicorn, copies the built frontend (dist/) to /app/static, and serves it via a small Flask wrapper.

Result: ~1.1 GB total size instead of 6 GB, while fully functional (API + UI).

So my suggestion is to

  • use a multi-stage Docker build to separate build/runtime layers.

  • Clean apt caches and unneeded files.

  • Optionally provide two tags:

    • grampsweb:lite — minimal, for self-hosting

    • grampsweb:full — includes complete tools

This would massively reduce image and RAM footprint for typical users.

3 Likes
4

Hi,

you are right, but – as I’ve discussed multiple times – I will not commit to maintaining a lite image. It’s scope creep that I simply cannot reconcile with everything else that’s going on.

I would highly welcome somebody from the community stepping up and setting up a separate repo with automated builds of different flavours of images. I think many users would be happy about it.

What we can certainly do is to improve the build process of the default images. Please search the forum and the Github issue tracker(s) for existing discussions. Just earlier today something like that came up again in the context of the dev environment for example, see here: Extend the development environment for debugging and testing · Issue #708 · gramps-project/gramps-web-api · GitHub

So, long story short:

  • Yes, the build process can be improved (multi-stage builds, less frequently changig base image), but it is not a priority for me personally so I need somebody from the community to support
  • There will continue to be three separate images: backend-only, frontend-only, and both combined
  • We will continue to provide images for two architectures, amd64 and arm64 (armv7 has just been dropped)
  • There will not be any other image flavour built on the two main repositories (gramps-project/gramps-web-api and gramps-project/gramps-web). The images built in the CI will be full-featured images (i.e. contain all binary dependencies needed to exploit all features).

I hope you all accept these decisions - the line has to be drawn somewhere.

Again, let me stress: I would be very happy if somebody set up a repository somewhere that provides custom Gramps Web docker images.

1 Like
5

Clean apt caches and unneeded files.

This should be an easy first PR :slightly_smiling_face: :folded_hands:

1 Like