packaging: Overhaul Containerfile and use Temurin JRE #1303
Conversation
| - name: Install tools | ||
| run: | | ||
| sudo apt-get install jq | ||
| wget -O ~/codacy-coverage-reporter-assembly.jar https://github.com/codacy/codacy-coverage-reporter/releases/download/4.0.5/codacy-coverage-reporter-4.0.5-assembly.jar | ||
| export DOCKLE_VERSION=$(curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/') | ||
| wget -O ~/dockle.tar.gz https://github.com/goodwithtech/dockle/releases/download/v${DOCKLE_VERSION}/dockle_${DOCKLE_VERSION}_Linux-64bit.tar.gz | ||
| tar zxvf ~/dockle.tar.gz -C ~/ | ||
| export TRIVY_VERSION=$(curl --silent "https://api.github.com/repos/aquasecurity/trivy/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/') | ||
| wget -O ~/trivy.tar.gz https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz | ||
| tar zxvf ~/trivy.tar.gz -C ~/ |
There was a problem hiding this comment.
JQ and Docker are both already installed in a recent version in the GitHub Actions Virtual environment and since you don't seem to use trivy here, and it having an official action otherwise, I cleaned up this overhead
k3rnelpan1c-dev
force-pushed
the
package/temurin
branch
from
e32988e
to
7f7a3d9
Compare
k3rnelpan1c-dev
changed the title
k3rnelpan1c-dev
force-pushed
the
package/temurin
branch
from
7f7a3d9
to
d87bae9
Compare
|
@stevespringett sorry for the ping, but could I get your feedback on this and whether you would be interested in a GitHub Action based release workflow instead or as an alternative to your |
|
Thanks for the PR. I'll need a few days to review. |
* migrate to temurin form zulu * enable arbitrary UID support Signed-off-by: K3rnelPan1c <69395733+k3rnelpan1c-dev@users.noreply.github.com>
* slight cleanup * pass new build args to docker build Signed-off-by: K3rnelPan1c <69395733+k3rnelpan1c-dev@users.noreply.github.com>
* update JRE LTS from 11 to 17 * pin base image digest * fix UID, GID mismatch Signed-off-by: K3rnelPan1c <69395733+k3rnelpan1c-dev@users.noreply.github.com>
k3rnelpan1c-dev
force-pushed
the
package/temurin
branch
from
d87bae9
to
2366ed1
Compare
|
@k3rnelpan1c-dev - looks really good, the only thing that is missing for full OpenShift compatibility is: This is what I use in my Dockerfile that uses Are you please able to add it in? @Homopatrol FYI. |
|
I've run Note the following: This is the arbitrary UID assigned to my user and the user home is defined as |
|
Hi, first of all thank you two for this observation! |
|
@k3rnelpan1c-dev it appears that the container can certainly start up and analyse an SBOM with the home directory defaulting to Also, on a separate note to this topic, I've noticed you've amended the |
|
Hey @namloc2001, All things considered, I will offer the HOME env addition in a future PR and have to check the Healthcheck again :/ |
Description
I props these changes as I stumbled over this great tool while dealing with the aftermath that was the Log4Shell hell week and noticed that the Dockerfile could be improved. I did so since we would deploy dtrack to our OpenShift cluster which uses arbitrary UIDs, which is currently already supported by the fronted container yet not by the API server. And while I have made similar changes to packaging for an internal draft container to test deploy dtrack I wanted to offer these changes upstream as well.
Additionally, I noticed that there is the motivation to use the Eclipse-Temurin JVM based on the comment in #1213 (comment), so I took the liberty and migrated the Container to that alongside the other changes.
To answer questions as to why I did so via a multi stage build I advice to read the following to issues that may be a long read but should explain it:
slimcontainer jdk releases adoptium/containers#54TLDR: DockerHub apparently does not accept
slimimages anymore for theirOfficial Imagelabelled images and the 'old'adoptopenjdktoo did only offer Ubuntu, CentOS7 and WindowsServerCore images. So the common consensus is to utilize multi stage builds to copy the JDK/JRE from a official image to a derived image with the same package manager (i.e. Ubuntu to Debian, CentOS to UBI or Fedora, etc.), a good example could be the Jenkins Official Docker images, which use Jlink to minify the JDK and then copy it to their image. (I did the same without Jlink since the JRE does not have that nor need it to be slim)If there are any further questions or any feedback please feel free to share them I will come back to them as soon as possible.
Changes
mavenworkflow slightlyIssues
Notes
I noticed that you seem to use a bash script to release new version of dtrack and want to propose moving that to CI (GitHub Actions) as well. I would be up for submitting the necessary PRs to do so if you are interested 🙂
EDIT: there are now official musl builds of Temurin 11, 16 and 17 available, so if you ever want to offer an alpine spin alongside the debian one you can now without any glibc hackery for the Alpine JVM variant.