Info: New build of Docker image 2.26.0 does not contain GDAL

GeoServer GeoServer User
,
1

Hello,

with the new GeoServer release 2.26.0, the Docker image is built on top of the official tomcat base image for the first time. We now realized that in the old approach (changed by Switch to official Tomcat 9 - JDK 11 base image by ahennr · Pull Request #45 · geoserver/docker · GitHub) “gdal-bin” was installed, but “apt install gdal-bin” is currently missing in the new approach (so in the 2.26.0 image).

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:

FROM docker.osgeo.org/geoserver:2.26.0

RUN chmod 1777 /tmp \
    && apt update \
    && apt install -y --no-install-recommends gdal-bin \
    && apt clean \
    && rm -rf /var/lib/apt/lists/*

I will soon start a discussion (on the developer level) regarding this (as we still have other things in mind regarding this issue).

1 Like
2

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.

3

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.

4

@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.

2 Likes
5

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:

https://github.com/adoptium/containers/issues/641

6

Great hint. Thank you. I will keep that in mind

7

@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