ABCL Docker Images

[Eric Timmons]

Hi Alan,

Alan Ruttenberg <alanruttenberg at gmail.com> writes:

> Thanks for starting this. It would be a great contribution.
>
> Something I've wanted for a very long time is to have a checkpoint/resume
> for ABCL - would function like save-world in other lisps. Doing this would
> make it practical to build tools which use lots of code, such as my own,
> start up quickly and become practical for script usage. Docker allegedly
> has some support for this but I've never seen it work on MacOS. If this is
> something you have any awareness of how to do I'd love to see that
> integrated into an ABCL docker image.

I've never been able to get Docker checkpoint/restore to work for me. I
tried a while ago (IIRC, prompted by you asking a similar question on
slime-docker!) and ran into https://github.com/moby/moby/issues/35691
and I just tried again and am currently seeing
https://github.com/moby/moby/issues/41639. Unfortunately I don't have
the time to experiment with various Docker and CRIU version combos to
find one where they actually work together.

However, from what knowledge I have been able to gather, it appears that
nothing special needs to be added to the image to make C/R work. It
happens entirely outside the view of the running processes and is
supposed to just enable the process to pick up exactly where the
checkpoint happened, none the wiser that it got paused.

> Could you say a few words about the image OS environment and your
> considerations when choosing it, and a bit on how to understand the tags?

Sure! All official images must inherit from other official images and if
an official image exists for a needed software stack you're highly
encouraged to use it instead of installing the software yourself (to
help encourage layer reuse). I'm aware of at least three Java runtime
images: openjdk, adoptopenjdk, and amazoncorretto. My decision to use
openjdk as the base image was semi-arbitrary in that I've used openjdk
before, the in-tree Dockerfile for building ABCL from source uses
openjdk, and for other official images that support only one Java
runtime, openjdk seemed to be the most used. However, there certainly is
precedent for Java based images to support multiple runtimes via tags so
if ABCL users think that's important or if the default should be
changed, that's definitely something we can do.

For the Windows images, we're limited to what the Official Images team's
hardware is. They're running a version of Windows Server that supports
1809 at most, so that's why the Windows versions appear to be so old.

For Linux images, the openjdk image is built for both Debian Buster and
Oracle Linux 8. Buster is their default for Java versions < 15 and
Oracle Linux is their default for >= 15. I chose to make the ABCL images
default to Buster for all Java versions beacuse, personally, it seemed a
little ridiculous to change OSes that drastically based only on Java
version. I didn't create any Oracle Linux variants of the ABCL image
because Buster is almost certainly the most widespread base image and I
took a guess that ABCL users would prefer that. But if there's a desire
for Oracle Linux based images, they would be easy to add.

The openjdk image also builds for Alpine, but only on the cutting edge
versions of Java and they drop support for it as soon the Java version
reaches General Availability.

Last, the openjdk image does have tags for either a JRE or JDK install
of Java. I chose to use only the JDK since that's the most useful, but
if there is desire for images that have only the JRE, that is also
possible.

With that out of the way, onto the tags for ABCL! Every tuple in my
original email has a canonical tag of the form
$ABCL_VERSION-$JAVA_VERSION-$OS (note processor architecture is
omitted). For instance: 1.8.0-jdk15-buster. Then, each of these
canonical tags have aliases. These aliases either omit a segment of the
tag (if it is the latest version of that particular element) or provide
an alternate form.

For instance, 1.8.0-jdk15-buster, 1.8-jdk15-buster, and jdk15-buster are
all the same image. 1.8 is an alias for the latest release in the 1.8
series and because 1.8.0 is also the latest ABCL release, it's the
default ABCL version and is omitted. jdk in the java segment of the tag
is an alias for the latest supported JDK (currently 15). Last, there is
a latest tag that is an alias for the latest of everything (ABCL 1.8.0,
JDK 15, and Buster on Linux or if on Windows, the latest version of
Windows your OS supports).

The architecture is handled by pushing the images to separate
organizations on Docker Hub (such as arm64v8/ or amd64/ for the Official
Images program) and then tied together in the primary organization using
manifest lists. This results in Docker pulling the correct version of
the image based on your hardware (or what you request using the
--platform CLI flag).

Hopefully that helps!

-Eric