Today during a code review of my CI/CD scripts, I came up agst. the following issues with my peer.
- Was using a docker file which I then installed sdkman and then used sdkman to get the correct version of java and maven for my legacy project. I then used the docker-dind service to build my image using a gitlab runner. It is an oft used pattern documented within Gitlab as best practice. I was using an official image and amending it so that maven could run and build my WAR file. It has all worked fine. I also installed sdkman - so I can use this image for other flavours of maven legacy-jdk7.
None of this was original stuff but adapted from a blog by Szymon Stepniak [https://e.printstacktrace.blog/using-sdkman-as-a-docker-image-for-jenkins-pipeline-a-step-by-step-guide/]
Essentially I had an image with Maven 3.5.4 & Java 7.x.x-zulu, instead. I also set it up with a non-root user. With an .m2 folder settings.xml which is needed for Maven. It does my building of this legacy WAR file.
But, I was told to drop the idea of creating my slightly amended docker image and to use one that is already made up namely maven:3.2.5-jdk-7u65
Ques 1. I was using an offical image namely debian:stretch-slim and amending it slightly. Atleast, my Dockerfile will say what is happening to my image. So, all of it's provenance is all well known. So, why is that practice being frowned upon ?
Ques 2. I cannot find this image maven:3.2.5-jdk-7u65 on docker hub as a SAFE & OFFICIAL image to use ?
Ques 3. When I use the maven:3.2.5-jdk-7u65 , it complains that this image is deprecated, but continues, it also complains about some public gpg keys being out of use, but continues, and the Maven build fails. The POM directives I am using basically are not covered by maven:3.2.5
What should I do and how should I approach this task ? What is best practice ? Why can't I find many official legacy maven legacy jdk6,7 images ?
CodePudding user response：
There's a lot of "it depends", and one of the things it may depend on is your local legal compliance requirements. I would suggest either:
- Use a current version of a Docker Hub image, if it's allowed; or else
- Build an image based on a known and allowed distribution base image
One thing to be conscious of with the Docker Hub images is that there's a specific set of versions they support, and versions other than this aren't rebuilt at all. Consider the maven image: there are various variations on maven:3.8.5 out there. If you build your image FROM maven:3 and you docker build --pull then you will get updates on this, both in Maven and the underlying Linux distribution image. If you name a super-specific FROM maven:3.8.3 then it will never be rebuilt, even if the underlying Linux distribution or JVM has a critical security update.
You're probably seeing some of this with the maven:3.2.5-jdk-7u65 image you've found. The image exists on Docker Hub but it hasn't been rebuilt in a long time. (For that matter, even the oldest openjdk image is based on Java 8.) So you probably could use it, if you really wanted to, but I wouldn't treat it as reliable or maintained.
So if you really need a very very old version of Java (which will be end-of-lifed in just a couple of months) I'd suggest the approach you have now is the best one: start FROM a reasonably current Linux distribution that gets security updates, download the newest version you can (it looks like Java 7u80 is publicly available and 7u331 with a paid subscription) and rebuild it occasionally. It will be on you to take updates as they're released and as the base Linux image gets updates, but this will be more updates than the unmaintained image you found gets.