Docker builds, dropping java 8 and other proposals

hacking
1

We currently publish a lot of different docker images for each snapshot, way too many in my opinion (currently 12, full, light etc, jre11, jre8), i.e. for 5.4.2.20

We did switch from jdk to jre with the last major round of updates, moving towards smaller images and at the same time, ensuring our latest docker images are more or less CVE free, which is great

But some people need jdk images for things like GitHub - softwareCobbler/luceedebug: line debugger for lucee to work, it is also of course possible to upgrade one of the existing published images to use a jdk with a bit of docker scripting magic

I think we should stop publishing java 8 images as java 8 is no longer officially supported by Lucee

That could eliminate 4 images, making the docker build quicker and saving over 1.2GB of storage, java 17 is on the horizon too, so life gets complicated fast ,see the problem?

That still leaves 8 images before we start publishing additional jdk images for 11 or 17

Which java release are people using with Docker?

  • Java 8
  • Java 11
0 voters

We still have a lot of duplication of extensions on the file system too, which we want to look into, as per LDEV-4646 - reduce duplication of extensions on the file system

Another idea is to possibly swap out the far loader jar out once the the docker image is pre warmed, with just the light loader (sans extensions) which reduces each image by a further 60Mb

So for those using the official Lucee docker images, which image are you using?

  • Lucee, Nginx and Tomcat
  • Lucee and Tomcat
0 voters

But I don’t think we need to be publishing 16 or 18 builds per snapshot, so assuming we don’t publish java 8 anymore, perhaps we only publish java 11 sans ngnix for snapshots?

I seem to recall both @markdrew and @dom_watson suggesting that best practise would be not bundling Ngnix, but I appreciate that the bundles just works™ for some people, but obviously if Nginx has a CVE, that’s problematic

And lastly, a big thanks to @justincarter for all his work in this area

1 Like
2

Custom docker build; java 11; one container lucee/tomcat and one container with nginx

3

I’m not too concerned about the number of images or the time it takes to build, other than to;

  1. keep it manageable
  2. avoid build errors

The total number of images or storage in Docker Hub isn’t much of an issue I think, they will eventually remove old images that don’t get used (most likely snapshots) and keep the ones that do.

When chasing smaller images we hit a point of diminishing returns where the cost (time) to go smaller doesn’t provide much benefit, especially if you’re deploying on 10Gbps+ instances and your servers are caching the base image layers, it’s not necessarily pulling the entire Lucee base image every time you make a code change in your app (*depends on the environment and deploy processes). I think with the newer Ubuntu + JRE options the images are small enough to keep most of us happy.

The main issue we had recently is the change to the official Docker Tomcat base image, which switched from Debian to Ubuntu. There’s one bug that had been run into where newer Ubuntu 22.04.x images did not work on specific versions of Docker (a Docker upgrade can fix that, but this isn’t trivial) so we should perhaps provide Ubuntu 20.04.x images as well. There are additional base image OS options that we might be able to consider supporting, like Amazon Linux with the Corretto Java distribution, though that would be a future task to look into.

The matrix of images is made up of many things; Lucee version, Lucee variant (standard, light, zero), Tomcat version, Java distribution, base OS, Nginx support, plus platform architecture (e.g. x86, ARM).

  • It definitely makes sense to offer both JRE and JDK builds so I’ll add that back in as soon as I can – like hopefully this week.

  • Java 8 has LTS support to 2030 so I feel like it’s worth keeping those images as options for anyone who might need it (unless Lucee 6.x doesn’t work on Java 8?);
    https://blogs.oracle.com/javamagazine/post/java-long-term-support-lts

  • Tomcat 8.5 we can drop for Lucee 6.x I think? If anyone feels differently please let us know!

  • Nginx I’d definitely want to keep, we have dozens of apps that rely on it at Daemon. You can split nginx out into a separate container though it makes your build and deployment more complex in most scenarios.

TL;DR I think it’s fine for the matrix of images to grow in the short term, but some aspects might possibly shrink as well with Tomcat 8.5 and Java 8 support over time. The main thing for me is that it’s easy enough to maintain and the builds work, and it provides the best options that most people need while retaining as good backwards compatibility for exists users as we can :slight_smile:

4

implementing proprietary software like Ubuntu is a mistake.

Switching from something with legendary stability (Debian) to the Debian testing ring (Ubuntu) is a mistake.

FreeBSD is far more “secure”, stable and blindingly simple to use, even more so than “Ubuntu”

First setup the docker instance.

#!/bin/sh

wget https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-amd64-bootonly.iso

cat -> docker-compose.yml <<< EOL
---
version: "3"
services:
    freebsd-via-qemu:
        image: jkz0/qemu:latest
        cap_add:
            - NET_ADMIN
        devices:
            - /dev/net/tun
            - /dev/kvm
        volumes:
            - ./FreeBSD-13.2-RELEASE-amd64-bootonly.iso:/image
        restart: always
...
EOL
docker-compose up -d

in the docker “freebsd instance”

freebsd-update fetch
freebsd-update install
pkg update
pkg install

pkg install openjdk11

vi /etc/fstab 
add 
        fdesc   /dev/fd         fdescfs         rw      0       0
        proc    /proc           procfs          rw      0       0
save the file
mount -t fdescfs fdesc /dev/fd
mount -t procfs proc /proc
rehash

pkg install tomcat9
## 
vi /etc/rc.conf
tomcat9_enable="YES"
tomcat9_java_home="/usr/local/openjdk11"

Now download the LUCEE WAR and deploy it as a standard WAR

:slight_smile:

5

Recent images didn’t use Ubuntu by choice, there was just no other up-to-date option. These images have always been based on the official Docker Tomcat image. Up until late late year it did use Debian, then it switched to Ubuntu for most stable releases and Debian for bleeding edge only and there were no new Debian images being published in the official Tomcat repo.

Now it appears that a few days ago the Debian images are back again for Tomcat 9.x :tada:

image
image788Ă—577 65.6 KB

I’ll be switching back to those shortly.

1 Like
6

Actually from my screenshot in the previous post I’ve misread it, those are all Java 21 JDK images (jdk21-openjdk) which we can’t use :man_facepalming: so our original issue still stands.

I’ve trawled through the tags on the Docker Hub page and the main readme seems to be correct…

  • Debian is only used for for JDK21 images
  • Ubuntu (Jammy and Focal) are used for the JRE11 images
  • Ubuntu (Jammy and Focal) and Amazon Linux w/ Corretto are used for the JDK11 images

https://hub.docker.com/_/tomcat

There’s a GitHub issue that says the OpenJDK base images for Java versions <=17 are no longer available for them to use, which is a little strange considering Java 11 is LTS, but that’s the current state of things

Short version; we will have to use the Ubuntu images for the foreseeable future. I’m going to provide both versions as a choice, along with JRE and JDK for the best flexibility (size vs features).

1 Like