Design the offerings for Docker images containing Adoptium runtimes #1
Comments
|
One critical consideration for supported OS (base images) is support for security updates and a continued pipeline of rolling updates for base image CVEs. As such, the set of base images should be chosen carefully and with a proven record of updates. |
|
After scanning The Project Handbook[1] for “DockerHub” and reading the background information we needed, we've decided to go for the DockerHub namespace of |
|
I know there has been suggestions elsewhere that we should use Ubuntu 20.04 and CentOS7 as a minimal set, however with the changes to CentOS and trying to direct people towards CentOS Stream I would suggest initially only publishing Ubuntu 20.04 and then we consider (based on feedback where it is forthcoming) which version of CentOS/UBI etc. we go forward with as the next ones after Ubuntu 20.04, unless there's a particular know driver for choosing that one in the initial set. |
|
|
|
@karianna What do you mean by "the fully supported list that we previously had at AdoptOpenJDK"? Are you saying we had specific extra "support" for the Ubuntu 20.04 and CentOS7 at AdoptOpenJDK and nothing else? |
|
docker-library/official-images#10662 contains the matrix. Once that lands we can figure out how to link to that in our README.md file (hopefully we can autogenerate this). |
|
Forgive me for being pedantic but how does that PR related to "the fully supported list that we previously had at AdoptOpenJDK"? Is that a statement specifically for what AdoptOpenJDK has as official images? (Which is not clear from the statements above) |
|
You're right, I'm tired, that was a lazy comment, I'll delete it. |
|
Is there a rough idea of when image parity will be available between AdoptOpenJDK and Adoptium? The latest patch updates were announced ~22 days ago along with their corresponding CVEs. Historically with https://github.com/AdoptOpenJDK/openjdk-docker the updated images would be available within ~1 week. |
|
See docker-library/official-images#10662 for the progress - we're waiting on Docker (Hub) to accept the PR. |
|
I'm most specifically interested in @gdams comment > docker-library/official-images#10662 (comment)
Is Alpine support expected with that initial PR? or relatively soon thereafter? Will Alpine images be offered on previous JDKs that do not include JEP 386? Myself, and I imagine many other users, have an eagerness(or contractual obligation) to upgrade to images without known vulnerabilities. Previously, the timeliness of those releases allowed for leveraging the community images. I understand this release isn't the same as previous releases due to the switch between AdoptOpenJDK and Adoptium. But, I'm trying to determine if I need to roll my own JDK base layer, in the short term, to resolve the CVEs until those other distros are offered.
When can we expect this document? |
|
Ref my comment above about CentOS7, it appears similar conterns were raised at the official docker repo as to why it was needed and the response was that it was easier to copy the image from an RPM-based distro to another one
but the instructions ( |
This PR is on hold until we get more community feedback on whether we should have glibc based apline images. |
|
My 2 cents based on our previous adoptopenjdk experience, glibc alpine based images were easily the most used ones. Admittedly this is not scientific, and is based on issues created, slack postings and queries etc as we cannot get a breakdown of the various images from DockerHub. The main attraction of these images being the smaller sized images and lesser attack surface. Since there is a large user base of both 8 and 11 and no musl based builds available, it would be good to have atleast these two versions made available with alpine glibc. Java 11 Image sizes for reference |
|
Strongly against glibc-Alpine. We did this at New Relic, and it did not go well. The images are, in any case, not much smaller than a full Ubuntu / CentOS image - which kind of defeats the entire point. |
|
Is this the location you're looking for feedback? (albeit user, not maintainer) I disagree that it defeats the 'entire' point. Reduced attack (and vulnerability) surface is still potentially relevant independent of image sizes. I say potentially only because I haven't tracked CentOS actively in recent years, but it certainly appears true c.f Ubuntu or Debian base images. Just curious, since we've had gibc alpine images for a number of years on Adopt (and personally used them without obvious issue), were any of the alluded to (but not described) problems at New Relic observed with the Adopt images? Were those issues in the maintenance thereof, or the usage/behaviour in the wild? |
|
From an Alpine and security perspective, I'd defer to @kaniini for preferences. |
|
@chadlwilson Yes this is the preferred forum for feedback (But we'll take it in private too if anyone prefers!) |
|
JEP 386 has not been backported officially to any pre-16 version, even though certain vendors (namely Bell Soft, Corretto, and Azul, as far as I could find) have published musl-compiled JDKs for Java 11 and other pre-16 versions. I am not in favour of glibc-Alpine either as it does not provide the expected benefits of musl. I think that end users are more than capable of cooking their own Alpine-based images (with glibc) for any JDK version. At most, Adoptium may provide coordinates/docs on how to create such image. |
|
I am also all for muslc based JDK. Alpine itself has builds for JDK 8, 11 and 16 with muslc provided by community. AdoptOpenJDK had at least 16 which we used, because there were CVE against glibc and our customers did not want any security issue. We are creating our docker anyway, because it must be always having fixes for security, but having binaries will be essential (it is missing right now). It is not in your power to cover all needs, because even choosing Alpine version is hard (everyone has different needs). So I agree with you that having minimal set is good approach. Everyone else can do just "COPY" as you say. That is what we do. If you look on how glibc based docker is done compared to muslc one it is like night and day. Glibc one looks like a big hack (it is downloading binaries from other distro, etc.) Having native one would be very nice (like in AdoptOpenJDK 16). And important with having Alpine image and not using CentOS/Ubuntu is security fixes. This distro needs tiny bit of packages installed and tries to be very fresh so it is passing much better vulnerabilities scans. |
I'm curious about this. Are you saying that the Alpine project backported JEP 386 for jdk8u and jdk11u? |
|
@brunoborges I do not know what it means, but they have these builds: https://pkgs.alpinelinux.org/package/edge/community/x86_64/openjdk11 OpenJDK 8 was not updated and is still on 8.292.10 |
|
Jdk11 appears to rely on Portola patches with some additional modifications: https://git.alpinelinux.org/aports/tree/community/openjdk11/build.patch |
|
Thanks @chadlwilson and @koldat for the details. I'd like to highlight that even Oracle has decided not to release a musl-compiled JDK for 16, not even EA 17 (even though JEP 386 got merged in 16), as they don't feel it is mature, well tested, and stable enough. In the OpenJDK 16 GA release (https://jdk.java.net/16/), they noted the following:
In the 17 EA releases, there are no Alpine builds either. (https://jdk.java.net/17/) |
|
@brunoborges we are using musl adoptopenjdk 16.0.1 in production without any issue quite a long time. |
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
…nloading Adoptium/Eclipse Temurin builds Adoptium now publish validated Alpine Linux builds of Eclipse Temurin JVM, compiled directly against musl libc (rather than glibc). Using these would avoid the need to use the Alpine GLIBC package which is not recommended by the Alpine team, and which is no longer supported by Adopt in their own containers. See the long discussion at adoptium/containers#1 At time of writing we cannot move away from glibc because the Tanuki wrapper does not seem to work against musl, OR with either gcompat or libc6-compat compatibility layers (both seem to be missing some symbols). However this allows us to do so in future by changing the targetted `OperatingSystem` in the alpine and docker-dind `Distro`s
Really intereseting thread indeed. Where can we follow the progress on that @karianna ? |
|
@Campano - The work has largely been done and we produce Alpine builds for 17 and 11 and are working on it for Java 8. TCK work is strictly private though I'm afraid so folks just have to wait until it pops out :-) |
|
First, thanks for all of your support on this project. Second, I am unable to locate an arm64/v8-based (macOS on Apple M1/M2 hardware) eclipse-temurin for Alpine and JRE8: I can work around this by specifying amd64 platform, but that is a non-native version (Rosetta2) and much slower for us. Any help appreciated! |
We don't support that platform combination at this stage. |
|
If you switch off the Alpine variant, $ docker run -it --rm --platform linux/arm64/v8 --pull always eclipse-temurin:8-jre
8-jre: Pulling from library/eclipse-temurin
Digest: sha256:4000764645ff6ecdda48f02d02bf51f551dd30eaa43a6328ffa7e42e94338c11
Status: Image is up to date for eclipse-temurin:8-jre
root@7c472e024d8f:/# dpkg --print-architecture
arm64
root@7c472e024d8f:/# java -version
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.332-b09, mixed mode) |
|
I'm not sure I understand why only the Ubuntu releases provide arm64/v8 platform support. Not an option for me as we require Alpine for our Docker microservice containers. I know Alpine is heavily used by the community due to its small size and so was a little disappointed it is not supported. I would open a ticket, but sounds like it would be "not fix". |
|
@SourceNode #158 is a relevant issue. |
|
Thank you for @vielmetti , sorry I did not see it before now. |
|
@SourceNode If you wanted to experiment with it, you can pull nightly alpine tarballs from the artifacts on https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-alpine-linux-aarch64-temurin/ which you can incorporate into your own images, but obviously that comes with the standard "Use at your own risk, may not work, not fully tested" disclaimer. |
Updating the Docker files for IBM Semeru OE
A significant proportion of downloads for Adopt' builds traditionally come via the Docker image repository.
However, the Docker images have evolved over time to include number ous OS base images, tags, supporting libraries, and version support.
This issue is to capture the design for Eclipse Temurin images, with a goal of making the Docker repository simpler, easy to navigate and consume, while maintaining the information and resources that our users require. Discussion and raising requirements is encouraged!
The AdoptOpenJDK builds currently are published in a project managed repository (u/adoptopenjdk), in the official AdoptOpenJDK repository (_/adoptopenjdk), and in some instances also in the official OpenJDK repository.
For Adoptium, the proposal is as follows for Eclipse Temurin binaries:
Reduce the set of base images, and introduce a policy for removing obsolete versions
Too many distros make it difficult to produce and maintain them in a timely manner. The Adoptium project should be very selective about the base images that are being used, and should have a policy in pace to remove base images that fall out of support by their community.
Consider using a single base image OS, and encourage users to extract the Eclipse Temurin runtime into their own preferred distros using the Docker COPY operation.
Use the official repo at Docker exclusively.
Having a project repository and an official Docker repository can be confusion for end users. Providing we can transition the existing official repository we will use that exclusively for publishing the Eclipse Temurin images, rather than set up a new one owned by the Adoptium project.
Clear transition document for users who are used to having multiple distros.
To enable users to transition from the existing Docker image availability it will be necessary for the project to produce good documentation that explains how the Adoptium images can be used to achieve equivalence on each of the main different platforms and operating systems.
The text was updated successfully, but these errors were encountered: