GDAL base docker image

[jemacchi]

For references, check PR

[groldan]

Just a heads up that I'm waiting till #544 is finished before incorporating this as we'll need to create the base jre-gdal image and I'll be making some changes to the build process

[buehner]

Just FYI as @aaime mentioned this on discourse: adoptium/containers#641

Seems that using temurin base images has performance issues with JPEG encoding, so on a long term we should try to optimize this.

I am planning to start a discussion on the discourse developer forum soon. Also to find a common gdal base image (without JPEG performance issues) that can also be used for geoserver vanilla.

[jemacchi]

Just FYI as @aaime mentioned this on discourse: adoptium/containers#641

Seems that using temurin base images has performance issues with JPEG encoding, so on a long term we should try to optimize this.

I am planning to start a discussion on the discourse developer forum soon. Also to find a common gdal base image (without JPEG performance issues) that can also be used for geoserver vanilla.

So, correct me if I'm wrong.
It would be better to move out from temurin and use another base image, right ?
Then, are you planning to move the Geoserver vanilla docker image, to be based on something different than the temurin one ? (currently it's this https://github.com/geoserver/docker/blob/master/Dockerfile#L1C6-L1C39 ) tomcat:9.0.96-jdk17-temurin-jammy

I totally agree on having same root base image with GDAL (for GSCloud as much as standard Geoserver)

On any case, I would avoid to build based on a specific app container or Java
Instead of that I would do an incremental build of curated images definitions. ie. choose an OS, then GDAL,then the Java distro , build the GDAL JAVA bindings, and finally the app container (if apply, as in the case of std Geoserver). Then, and only then, to organize scripts around installing Geoserver (with a war file or with a zip, as when done with the Jetty embedded server)

btw, in GSCloud, the "apps" dont use Tomcat :). So using Tomcat in std Geoserver is a matter of a decision on the std Geoserver docker image, if we plan to share same base images, we need to agree on keep it agnostic of some high-level layers definitions, and just agree on the basic ones (OS, Java, GDAL).

Count me for getting this done

[groldan]

update: building the gdal lib ourselves in a github actions workflow takes over 2hs, so not too fond of it.

Meanwhile, my current experimental branch is using the latest (3.9.2) official osgeo GDAL docker images.

There are two of them:

• ghcr.io/osgeo/gdal:ubuntu-full-3.9.2
• ghcr.io/osgeo/gdal:ubuntu-small-3.9.2

The full version comes with the java jar and native JNI library, the small version doesn't.
Question is whether to use the full version as base image or the small one with a multi-stage build that grabs the jar and native library from full.

Btw, 3.9.2 images are based on ubuntu:24.04, prior ones on ubuntu:22.04. Seems like a good base to install the JRE on top, and eventually Tomcat for the vanilla GeoServer base image.

[pmauduit]

Question is whether to use the full version as base image or the small one with a multi-stage build that grabs the jar and native library from full.

Why not using the full as multistage and grabbing all the necessary stuff (libgdal, libgdaljni, the jar native glue) from there ? even if the .so and the jar should be compatible across both full & small images, at least you will have everything you need in one go.

[jemacchi]

agree with @pmauduit , using the full as builder and getting what we think it's useful sounds like a good approach.

[groldan]

I'm not sure I understand. The small image already have libgdal and apparently a smaller list of supported formats.
All we need to do is to grab libgdaljndi and gdal.jar from the full and build a new one based on the small version

[pmauduit]

I'm not sure I understand. The small image already have libgdal and apparently a smaller list of supported formats.

What I meant is that I would rather use all the binary materials from the same image, instead of mixing them, as you are sure that the jni bindings will work with the raw GDAL lib from the same place. But if you intend to use the small (because smaller binary size, less supported formats) on purpose, then I have no idea.