Hi all,
with the upcoming release of Camunda BPM platform 7.9.0 on 31st of May there are also some major changes to the community Docker images.
tl;dr:
- drop of Java 7 and JBoss support
- support for Wildfly 11
- switch from Oracle JDK to OpenJDK
- switch from Ubuntu to Alpine base image
- Java process runs under tini and as camunda user
- new tagging schema where
latestpoints to last stable minor version - build your own EE image support
- old images are archived
Drop of Java 7 and JBoss support
Camunda BPM platform is distributed for multiple application servers. The community Docker image offered a flavor for Apache Tomcat, JBoss AS 7.2 and Wildfly 10. Where JBoss AS 7.2 was the only application server still requiring Java 7 to run. This increased the maintenance cost and with Java 7 basically unsupported led to a lot of problems. With the upcoming Camunda BPM platform release 7.9.0 another application server Wildfly 11 will be supported. To simplify the maintenance and support only the latest application servers the support for JBoss was dropped. And therefore the need to provide a Java 7 image.
Support for Wildfly 11
With Camunda BPM platform 7.9.0 the Wildfly 11 application server is supported. Therefore the docker image will now be build with Wildfly 10 and Wildfly 11 flavor with the upcoming releases. To choose the distro use either the wildfly10 or wildfly11 tag. Note the wildfly is no longer available.
Switch from Oracle JDK to OpenJDK
Installing and distributing Oracle JDK is neither simple nor are the legal consequences clear. My personal experience is that there is not much difference between them since Java 8. Also OpenJDK provides official Docker images which can be used as base image which minimized the Dockerfile of the Camunda BPM
platform significant.
Switch from Ubuntu to Alpine base images
Alpine is a Linux distributing which is focused on providing a minimal Linux environment. It became quite popular in the Docker community and is often used to provide minimal size images.
The OpenJDK 8 docker images are provided as Debian Stretch or Alpine flavor, where the size difference is somewhere around 500MB. By switching to the OpenJDK Alpine image as base image for the Camunda BPM platform the image has a minimal overhead compared to the size of a bare-metal Camunda BPM platform
installation.
Java process runs under tini and camunda user
The process started in the Camunda BPM platform image will now be a child process of the tini process. This prevents the Java process to run as pid 1 which can lead to various problems if a user tries to get some diagnostics like a heap dump out of the container.
Also the Java process now runs as camunda user and not longer as root user which is a common best practice.
New tagging schema
You can read about the whole schema in the README file on GitHub.
The most notable change is that the latest tags no longer point to the latest released Camunda BPM platform version including alpha releases. It will from now on always point to the latest stable minor release. So for example end of next week the latest tags will point to the 7.9.0 images for half a year until 7.10.0 is release. The alpha images will still be provided but not longer tagged as latest.
Other than that the jboss tag is gone as the support is dropped. And the wildfly tag is split up into wildfly10 and wildfly11.
Also as of next week Camunda BPM platform 7.6.0 as reached end of life and therefore the images will only be available from Camunda BPM platform 7.7.0 onwards.
Build your own EE image support
With the drop of Java 7 and the switch to Alpine we were able to create all versions and distributions from a single Dockerfile. With the use of Docker multi-stage builds it is even possible to split the download/unpacking step from the final image.
This allowed us to provide a simple way to build your own enterprise images if you want to, without exposing the enterprise credentials in the final docker image. See the README on GitHub for a guide how to build an enterprise image.
Old images are archived
Today I deleted all old Docker images from DockerHub and replaced them with the once build with the new Dockerfile. In case you still want to build one of the old images or want to reuse the Dockerfiles you can find them all on the archive branch on GitHub.
Let me know if you have any feedback or create an issue on GitHub if you want to improve the images.
Cheers,
Sebastian