In case your deployment depends on GDAL (for example by using extensions that need it), things will probably fail. The following Dockerfile snippet demonstrates a fix/workaround for this scenario:
How does it work with docker images? Can you just make a 2.26.0-1 or something?
aside: This is part of the fun of not having a release candidate. The real-world feedback is always needed - the community just needs to choose when that occurs.
Hi,
this is going to be “fun” as those images, AFAIK, does not contain libgdal-java, since Debian dropped
that library years ago. You’ll have to change the docker image build and compile the GDAL bindings
during the image build I’m afraid.
@jive It should be possible to manually release something like “2.26.0-1”, but I don’t think we need that here. GeoServer vanilla doesn’t rely on GDAL, so in my view our base image shouldn’t include GDAL either. I just wanted to let people know in case they are depending on something that is now missing. The lines I suggested as a fix/workaround for these scenarios should allow anyone to reinstall the package for their setup - just in case it’s really needed somewhere. But so far I haven’t heard of people missing it.
As @aaime-geosolutions mentioned, to make gdal fully available in the image, we would have to build and compile GDAL bindings, which would probably lengthen the build process significantly.
Since we had a code sprint for the geoserver-cloud project last week and there are also requirements for images with GDAL, the idea came up to develop common base images at osgeo level, e.g. for “GDAL/Java”. We could then consider providing one image with and one image without GDAL in the long term. The GDAL variant could then be used by the vanilla geoserver Dockerfile as well as in the geoserver-cloud images. I will try to start a separate discussion on this in the coming days.
Hi,
if you’re working on a base image, I would recommend also doing something about the JPEG encoder slowness in
Temurin builds (e.g., switch to use the distribution JDK instead). More details here:
@buehner let me know if I can help with the GDL+Java base image in some way (you know it would be really interesting to setup a common base image for both GSCloud and Geoserver vanilla).
Shared some comments here
For the vanilla geoserver Dockerfile, I do currently not plan to always include GDAL (as vanilla GeoServer does not require it).
As the process of compiling and building an image with GDAL takes some time, I dont think it makes sense to introduce a ENV that would allow to do this in the startup script (as you would have to wait minutes until GS would start).
But on mid-term it probably makes sense to provide two variants of the (vanilla) GeoServer docker image: One without GDAL (the one we already have) and another, additional one with GDAL, so this could be used by people that require full GDAL integration.
As @josemacchi said, the GS cloud project also depends on GDAL, so from our perspective, it makes sense to find/create common base images (on the osgeo level) for both projects. In this context, we should also consider the hint of @aaime-geosolutions regarding the JPEG encoder slowness in
Temurin builds.
I’ll be on vacation for the first two weeks of November and won’t have time to start on this before then. But I’ll be in touch at the end of the year to tackle this topic.
The latest (3.9.2) official osgeo GDAL docker image comes in two flavors:
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 native 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
If so, it’d be great to have both GeoServer and GeoServer Cloud using the same GDAL base image.
Worth noting also it seems the small gdal image comes with fewer supported formats for gdal/ogr. Didn’t make an exhaustive check to see if the small image would be too limited in regard to the formats GeoServer would expect, but I seem to remember it doesn’t come with NetCFD support.
If that will end up being a problem maybe we can just use the full image and call it a day. I’m sure there will be stuff we can remove though, like pyhton?