Deprecation of openJDK docker images #2288
Labels
dependencies
Pull requests that update a dependency file
distribution
Issue refers to target platform, e.g. Docker
Comments
|
Hey, thanks for taking a look at it! I personally don't like an idea of having all of them - it adds a little bit of mess for no clear reason. I'd probably go for Liberica from BellSoft that is usually my go-to distribution. An especially good reason for that in our case is that they're maintaining good old JRE targets:
And those are just small out of the box. Of course we need to double-check if Reposilite is actually still able to start on it 👀 |
|
Added the BellSoft images to the list of images, will take a look at them and hammer out a Dockerfile for it and add it to the to be tested pile. |
tech-6
added a commit
to tech-6/reposilite
that referenced
this issue
Nov 24, 2024
Default user and group id is now 977 as 999 was taken.
!!**This may cause permissions issues in existing installations**. These 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 as a privileged user. When the container is running there is no code executed in a privileged context.
Proposed Solution to dzikoysk#2288
tech-6
added a commit
to tech-6/reposilite
that referenced
this issue
Nov 24, 2024
Default user and group id is now 977 as 999 was taken.
!!**This may cause permissions issues in existing installations**. These 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 used. When the container is running there is no code executed in a privileged context, as anything requiring privileges is run during build time.
Proposed Solution to dzikoysk#2288
tech-6
added a commit
to tech-6/reposilite
that referenced
this issue
Nov 24, 2024
Default user and group id is now 977 as 999 was taken.
!!**This may cause permissions issues in existing installations**. These 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 used. When the container is running there is no code executed in a privileged context, as anything requiring privileges is run during build time.
Proposed Solution to dzikoysk#2288
tech-6
added a commit
to tech-6/reposilite
that referenced
this issue
Nov 24, 2024
Default user and group id is now 977 as 999 was taken.
!!**This may cause permissions issues in existing installations**. These 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.
Proposed Solution to dzikoysk#2288
|
With the proposed change to the BellSoft Liberica base image. There will be compatibility issue that would require users of the current image to apply a fix while upgrading. More information about the changes is detailed out in #2289. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of December 20th 2022 the openJDK images from the docker library were deprecated (see docker-library/openjdk@d2f1e2d and docker-library/openjdk#505). With this comes with a handful of questions for continuation of the reposilite docker images. Below are some choices to go with moving forward.
One base image to rule them all
Pick a new single base image for future reposilite images
amazoncorretto:${JDK}-al2023based off of Amazon Linux 2023amazoncorretto:${JDK}-alpinebased off Alpine Linuxeclipse-temurin:${JDK}based off Ubuntueclipse-temurin:${JDK}-alpinebased off Alpine Linuxeclipse-temurin:${JDK}-windowsservercorebased off Windows Server 2016 (I advise against this one)bellsoft/liberica-runtime-container:jre-${JDK}ibm-semeru-runtimes:open-${JDK}based off Ubuntusapmachine:${JDK}based off UbuntuWith one of these images rework the Dockerfile to use said image.
Example
How about all of them
Publish a build for x amount of base runtime images using artifacts from a build image. Allowing users to choose their preferred JVM runtime to run their repo with. A method of doing this could be using
docker buildx baketo make a build job to build the JAR file and cache them for building the runtime images (which could be done in parallel).More commentary is wanted or more potential solutions. Many thanks.
The text was updated successfully, but these errors were encountered: