There are 3 updates, 1 comment.
 
 
XWiki Docker images / cid:jira-generated-image-avatar-9908ba90-a1fa-4fdc-a0ce-38c86f6e2af0 XDOCKER-8 Closed

Also offer an alpine-based image to reduce download size

 
View issue   ·   Add comment
 

3 updates

 
cid:jira-generated-image-avatar-79a3bf96-8f43-4793-bad9-40bb5137c932 Changes by Vincent Massol on 26/Jul/26 12:49
 
Assignee: Ashish Sharma Vincent Massol
Resolution: Won't Fix
Status: Open Closed
 
 

1 comment

 
cid:jira-generated-image-avatar-79a3bf96-8f43-4793-bad9-40bb5137c932 Vincent Massol on 26/Jul/26 12:51
 

Closing this as Won't Fix: the premise of the issue no longer holds, on both counts.

There is no Alpine base image to build on anymore

The official tomcat image dropped its Alpine variants. The last ones (tomcat:8-jre8-alpine and tomcat:9-jre8-alpine) were last pushed on 2019-05-16 and nothing has been published since. The current library/tomcat definition in docker-library/official-images offers only Ubuntu noble/jammy + Temurin and Amazon Linux 2 + Corretto — neither "alpine" nor "slim" appears in it at all.

Basing the XWiki image on Alpine would therefore mean building and maintaining our own Tomcat-on-Alpine base image. For an image that is part of the Docker official-images program, that is a permanent maintenance liability we don't want to take on.

The size argument has been overtaken by reality

Layer breakdown of xwiki:18 (amd64, compressed sizes, 653 MB total):

Layer MB % of image
XWiki WAR (unzipped) 344.9 53%
LibreOffice 191.2 29%
Temurin JRE 53.1 8%
Ubuntu rootfs 29.7 4.5%
Base apt dependencies 16.9 2.6%
Tomcat 14.4 2.2%
JDBC driver 1 to 2.4 0.4%

Alpine would only replace the rootfs and the base apt dependencies, i.e. about 47 MB out of 653 — and the Alpine rootfs is not free either. A musl JRE is not meaningfully smaller, and Tomcat, LibreOffice and the WAR are unchanged. The realistic best case is around 40 MB, i.e. roughly 6% of the image. When this issue was created in 2017 the ratio was very different; today the base OS is noise.

Against that 6% we would pay:

  • The variant matrix doubles: 3 variants become 6, times the 4 maintained cycles = 24 generated directories, each needing a smoke test and an entry in the official-images file.
  • We would lose what XDOCKER-157 just introduced. The Document Foundation only ships glibc .deb/.rpm builds, so we could no longer install the exact LibreOffice version XWiki supports and tests against. Alpine does have libreoffice in its community repository, but pinned to the Alpine branch (v3.24 has 25.8.7.3, v3.23 has 25.8.1.1, v3.22 has 25.2.5.2), so the LibreOffice version would follow Alpine's release cycle instead of XWiki's supported LTS.
  • musl vs glibc for LibreOffice and JODConverter — the objection already raised on this issue back in 2018 — remains valid and is now largely untested territory.

About the pull request

The PR at https://github.com/xwiki/xwiki-docker/pull/20 is being closed at the same time. It adds directories under 10/ and 11/, cycles that no longer exist (the repository now maintains 16, 17, 18 and 18.4); it proposed renaming the variants to mysql-tomcat-debian/mysql-tomcat-alpine, which would break every published Docker tag; and it was never fully converted to the template mechanism as asked for at the time. There is nothing in it that can be applied to the current template/ + build.gradle setup.

If download size is the real concern

The lever is LibreOffice, not the base OS: 191 MB, 29% of the image, about five times what Alpine could ever save. A LibreOffice-less variant (or making the LibreOffice install optional at build time), combined with XWIKI-22481 which would allow using a LibreOffice binary running on another server, would give a container-native slim image. That is worth a separate issue if someone wants to pursue it.