Change base image for Dockerfile

[tech-6]

• Default user and group id is now 977 as 999 was taken.

Caution

!!This may cause permissions issues in existing installations.
The above mentioned permissions issues can be fixed by either:

• mounting the volume with another container as a root user and changing ownership of /app/data (including their contents) to 977:977
• chmod -R 977:977 /var/lib/docker/volumes/${VOLUME_NAME_OR_HASH} of the volume from the host's volume directory.
• chmod -R 777 /app/data (don't do this)

• Dockerfile and entrypoint.sh was changed to run NO application code as a privileged user. When the container is running there is no code executed in a privileged context, as anything requiring privileges is run during build time.
• Addition of a .dockerignore file to ignore non-application files and improve docker cache hits.

Proposed fix #2288

[tech-6]

Seems ready for review, has been stable in my testing environment.

[dzikoysk]

Hmm... I'm a bit worried about changing current behaviour - we have quite wide variety of users, even on some exotic setups. That's also the reason why we basically moved a lot of the logic to the entrypoint.sh script.

I think it requires deeper investigation, I'll try to check some historical issues. I guess you could also browse them by searching for Dockerfile or entrypoint keywords.

[tech-6]

The main issues that came to mind are #1762, #1200, #1634.

• Docker container running as root #1200 would continue to be resolved as we would be running as non root.
• Error deploying in OpenShift because of chown #1657, Image requires to be run as root and does not support random uids #1762 Pertain to opinionated K8s distributions, more research needed to determine compatibility

Below is a todo list on testing deployments,

• docker-compose.yml Deployed to mvn.littleoni.net
• Kubernetes (I'll most likely try it on my home "cluster")
• Redhat Openshift re: Error deploying in OpenShift because of chown #1657 Image requires to be run as root and does not support random uids #1762 Deployed to openshift.mvn.littleoni.net

Could be helpful to see if the users from #1657 and #1762 if they got it up and running and for potential testing.

[tech-6]

Confirmed a working fresh install on RedHat Openshift (see above link)

Seems like Openshift's UID randomization still works with user 977 and the rootless container.

[solonovamax]

A few questions:

• Why was a liberica jdk chosen over a jdk from eclipse temurin (eg. eclipse-temurin:21-jre-alpine)? What is the benefit of this? Looking at https://whichjdk.com/, there does not seem to be any significant benefit, so I'm unsure why it was chosen.
• Why was a docker image with Class Data Sharing chosen for the build stage, even though it is never enabled/used?

[dzikoysk]

Why was a liberica jdk chosen over a jdk from eclipse temurin (eg. eclipse-temurin:21-jre-alpine)? What is the benefit of this? Looking at https://whichjdk.com/, there does not seem to be any significant benefit, so I'm unsure why it was chosen.

1. It's smaller

• eclipse-temurin:21-jre-alpine - 71mb
• liberica-runtime-container:jre21-slim-musl - 45mb
• liberica-runtime-container:jre-21-cds-slim-musl - 52mb

2. I didn't know they have JRE builds

One nice thing about temurin is that maybe we could avoid changing user & group ids.

Why was a docker image with Class Data Sharing chosen for the build stage, even though it is never enabled/used?

I think we should go for the smallest one as long as it works. If that's possible, I guess it'd be nice to have a build without cds.

[tech-6]

• Why was a docker image with Class Data Sharing chosen for the build stage, even though it is never enabled/used?

That's on me, Bellsoft's tag page is crazy full, will be pushing no cds on build stage shortly.