Lucee Docker Image Release Cycle


#1

Docker images should closely follow the official release of stable versions of Lucee. If a Docker image is “late” feel free to harass the maintainers @modius and @justincarter on PM.

It is a manual process at the moment; we’ve been trying to automate the process but tragically it’s trickier than it looks within a single repo.

The github repo:

The Docker Hub registry; https://hub.docker.com/u/lucee/

Stable Images

We release two types of image:

  • lucee neat (lucee4, lucee5, lucee51); just lucee on its own serving on port 8080
  • lucee compounded with NGINX (lucee4-nginx, lucee5-nginx and lucee51-nginx); lucee fronted by NGINX web server on ports 80/443

If you have no idea which you should prefer, always select the lucee-nginx variant.

Every image is tagged with its own version number. The most recent stable release is also tagged as :latest.

Note, we do not recommend using :latest in production as you may unexpectedly upgrade your application when you next rebuild your project.

Beta Images

We will occasionally release major beta milestones as images to the community. If you need SNAPSHOTS you will need to build your own image locally.

Inherited Images

We currently inherit the official Tomcat image, based on the OpenJDK and Debian images.

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

We patch tomcat to the latest 8.0.x with each stable release. If we need to patch tomcat between stable builds of Lucee server we add the Tomcat version as an extension to the label.

5.0.0-t8.0.36
5.0.0-t8.0.35

Note, Tomcat patches include any changes to the underlying Java and Debian image layers. This is only done if there are significant security patches released for Tomcat between the release of stable Lucee builds._

Note, we are working on an additional Alpine Linux based distribution for a smaller image footprint. However, it’s not ready for prime time.

Image Testing

If it spins up it’s good to go. ie. we assume the core engine testing on stable builds provides coverage for the engine in the image.

It is possible that we could introduce some sort of configuration artefact that might affect the running of the image. Or the underlying Tomcat image could theoretically introduce an issue. However, it’s not something we’ve encountered to date.

Helping Out

As a general rule we don’t need pull requests for version bumps; we go through a multi-step process to update the JARs, spin up locally, commit and tag changes, build remotely and push the image to docker hub registry – much of this is a manual process that has thus far been hard to automate within a single repo.

Please raise docker specific issues either here on http://dev.lucee.org or as issues on GitHub. Docker specific issues should not be raised in the general Lucee Server issue tracker.

We are looking for folks to share their configs, customisations and optimised set ups for Docker installations; please share them here on the forum. If we start to see patterns emerging we do assist by improving the base image and/or improving Lucee core to make Docker a first class deployment strategy.

Remember: Batteries Not Included

Lucee official images are base images. This means that you should be inheriting them from a project specific Dockerfile and not using them directly.

For example, a minimalist project Dockerfile would look something like:

FROM lucee/lucee4-nginx:latest
COPY code /var/www

#2

Latest Docker images released for both neat and NGINX variants:

  • 5.1.2.24
  • 5.0.1.85
  • 4.5.5.006

All images are based on the official Tomcat 8.0.41 image; https://hub.docker.com/_/tomcat/

Note, we’ve had to move builds for the Lucee 5.1.x releases to its own Docker :whale: registry repo lucee51; ie. new releases will no longer be available under lucee5.

h/t @justincarter


#3

So lucee/lucee5:latest will give you the latest 5.0.x, and lucee/lucee51:latest will give you the latest 5.1.x

The problem with having 5.0.x and 5.1.x in the lucee/lucee5 repo is that it would make the “latest” tag unusable since it would flip flop between 5.0.x and 5.1.x depending on the order of pushes, so separate repos solves this

It also keeps the builds a little simpler for now, until we have a chance to put a fully automated build process in place that does all the magic for us :tophat: