Inherited Images

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:

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