Design the offerings for Docker images containing Adoptium runtimes

tellison commented 3 years ago

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.

jerboaa commented 3 years ago

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.

karianna commented 3 years ago

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 eclipse-temurin and will ask Docker to make those official images.

[1] https://www.eclipse.org/projects/handbook/

sxa commented 3 years ago

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 commented 3 years ago

~I think this is resolved now. We have the fully supported list that we had previously at AdoptOpenJDK. We do need to add a link to the official DockerHub repo CC @gdams~

sxa commented 3 years ago

@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?

karianna commented 3 years ago

https://github.com/docker-library/official-images/pull/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).

sxa commented 3 years ago

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)

karianna commented 3 years ago

You're right, I'm tired, that was a lazy comment, I'll delete it.

mattnelson commented 3 years ago

Is there a rough idea of when image parity will be available between AdoptOpenJDK and Adoptium? Or some guidance for the community to help reach parity through contributions?

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.

karianna commented 3 years ago

See https://github.com/docker-library/official-images/pull/10662 for the progress - we're waiting on Docker (Hub) to accept the PR.

mattnelson commented 3 years ago

I'm most specifically interested in @gdams comment > https://github.com/docker-library/official-images/pull/10662#issuecomment-897889255

We don't plan on adding any other distros (other than perhaps Alpine at some point)

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.

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.

When can we expect this document?

sxa commented 3 years ago

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

Our reasoning behind an ubuntu and a centos repo is that centos is RPM-based so the JDK can be easily copied into Rhel/Clefos etc, and Ubuntu is debian based so covers all the apt distros

but the instructions (Use a base image) from https://hub.docker.com/_/eclipse-temurin/ appears to just copy from the default Ubuntu image if I'm reading it properly. Also they should also be identical since we're copying into the docker image from a tarball, not an RPM/DEB package (which would likely install into a different location from where we are putting them in the docker image)

karianna commented 3 years ago

See docker-library/official-images#10662 for the progress - we're waiting on Docker (Hub) to accept the PR.

This PR is on hold until we get more community feedback on whether we should have glibc based apline images.

dinogun commented 3 years ago

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

$ docker images
REPOSITORY                                   TAG                IMAGE ID      CREATED        SIZE
docker.io/adoptopenjdk/openjdk11             alpine-jre         6cf1fc1047fc  20 hours ago   149 MB
docker.io/adoptopenjdk/openjdk11             centos-jre         13dbb45d8dc0  20 hours ago   486 MB
docker.io/adoptopenjdk/openjdk11             ubuntu-jre         398ce73b3bf4  20 hours ago   249 MB

docker.io/adoptopenjdk/openjdk11             alpine             b6e96c767b1a  45 hours ago   343 MB
docker.io/adoptopenjdk/openjdk11             centos             2e830ca52a50  45 hours ago   679 MB
docker.io/adoptopenjdk/openjdk11             ubuntu             231c7df92d0b  44 hours ago   443 MB

kittylyst commented 3 years ago

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.

chadlwilson commented 3 years ago

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?

vielmetti commented 3 years ago

From an Alpine and security perspective, I'd defer to @kaniini for preferences.

sxa commented 3 years ago

@chadlwilson Yes this is the preferred forum for feedback (But we'll take it in private too if anyone prefers!)

brunoborges commented 3 years ago

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.

koldat commented 3 years ago

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.

brunoborges commented 3 years ago

Alpine itself has builds for JDK 8, 11 and 16 with muslc provided by community.

I'm curious about this. Are you saying that the Alpine project backported JEP 386 for jdk8u and jdk11u?

koldat commented 3 years ago

@brunoborges I do not know what it means, but they have these builds: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/openjdk16

root@6X1ZHP2:~# docker run -it alpine:3.14
/ # echo "@testing http://dl-cdn.alpinelinux.org/alpine/edge/testing/" >> /etc/apk/repositories
/ # apk update && apk add openjdk16-jdk@testing
/ # java -version
openjdk version "16.0.2" 2021-07-20
OpenJDK Runtime Environment (build 16.0.2+7-alpine-r0)
OpenJDK 64-Bit Server VM (build 16.0.2+7-alpine-r0, mixed mode, sharing)

https://pkgs.alpinelinux.org/package/edge/community/x86_64/openjdk11

root@6X1ZHP2:~# docker run -it alpine:3.14
/ # echo "@testing http://dl-cdn.alpinelinux.org/alpine/edge/community/" >> /etc/apk/repositories
/ # apk update && apk add openjdk11-jre-headless@testing
/ # java -version
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-alpine-r0)
OpenJDK 64-Bit Server VM (build 11.0.12+7-alpine-r0, mixed mode)

OpenJDK 8 was not updated and is still on 8.292.10

chadlwilson commented 3 years ago

Jdk11 appears to rely on Portola patches with some additional modifications: https://git.alpinelinux.org/aports/tree/community/openjdk11/build.patch

brunoborges commented 3 years ago

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:

The Alpine Linux build previously available on this page was removed as of the first JDK 16 release candidate. It’s not production-ready because it hasn’t been tested thoroughly enough to be considered a GA build. Please use the early-access JDK 17 Alpine Linux build in its place.

In the 17 EA releases, there are no Alpine builds either. (https://jdk.java.net/17/)

koldat commented 3 years ago

@brunoborges we are using musl adoptopenjdk 16.0.1 in production without any issue quite a long time.

brunoborges commented 3 years ago

I believe in that, but from a vendor perspective, one successful customer deployment is not enough. Your use of the JDK may not be covering all of the possible scenarios and use cases.

koldat commented 3 years ago

That is true. You are right. Just giving you information I have. Our deployment is not small. It is more than 100 containers with different applications and frameworks and total jar size of several gigabytes. But true it does not need to be all....

kaniini commented 3 years ago

FYI: I have proposed an update in Alpine which blocks the installation of alpine-glibc. We are so very tired of this.

kaniini commented 3 years ago

As @kittylyst notes:

Strongly against glibc-Alpine. We did this at New Relic, and it did not go well.

It does not go well because trying to run code compiled for musl on glibc (and vice versa) results in a situation where you have two very different ABIs (the ones used by the app and system libraries) trying to work together.

You need to use an appropriate emulation layer like gcompat if you want to run glibc binaries on a musl host. This is like trying to run Windows programs on OS/2: yeah, both support EXE files, but they're otherwise two very different animals.

kaniini commented 3 years ago

A longer post on my blog explaining why alpine-glibc is bad and should never be used in production: https://ariadne.space/2021/08/26/there-is-no-such-thing-as-a-glibc-based-alpine-image/

ncopa commented 3 years ago

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.

The real long-term solution here is to have someone (Oracle?) to provide a stable and tested the musl-compiled JDK. If JDK requires glibc there is basically no point in using Alpine.

Other option is to provide statically built JDK binaries, which does not depend on any files at all from the host OS.

Mixing glibc with musl libc is generally a bad idea. It might or might not work and there are no guarantees that it will work with future versions of musl or glibc.

EDIT: @kaniini pointed out to me that statically built JDK might not work due to JDK using dlopen(3).

chadlwilson commented 3 years ago

As a downstream user of Java/Adopt, the insights here are very interesting, and appreciated (yet probably a little beyond me to assess the risk - but that's OK!).

Also as a user, I am equally bemused by my success of using the previous AdoptOpenJDK alpine+glibc images for the few years they have been available now, without obvious issues caused by the risks mentioned above. I also frequently come across other Java-based projects using Adopt Alpine as their base images (or using the same approach whether advisable or not). Perhaps that is to do with the nature of the containers (nothing else in them other than JDK?) or particular use of the JVM.

In any case

I value Alpine because of its quality, low attack surface area and solid records as such (anecdotally?) requiring less frequent patching for security issues
I value Adopt(OpenJDK|ium) because of its published LTS strategy around Java builds, quality/testing of its builds and track record of producing security patch releases quickly (as both binary and container images)

It's unfortunate we seem to not have a great strategy to combine these two great projects (and arguably Alpine+Java at all?) to get these benefits without some trade-offs that appear to be difficult to assess.

What I mean is that it's in general probably a challenge for users to determine the trade-offs between the choices of

Use Alpine with OpenJDK + patches/hacks from Alpine packages (e.g https://pkgs.alpinelinux.org/packages?name=openjdk11&branch=edge)
Use Alpine with Adopt (implying somewhat hacky/risky glibc usage as noted above)
Use something else entirely like Bell Software's Liberica musl JDK builds (personally I was uncomfortable of using builds backed by a smaller outfit)
Don't use Alpine at all. :'(
...other?

kaniini commented 3 years ago

I don't want to suggest a competing implementation, but Azul does offer their Zulu product for Alpine. It is certified and you can even buy a support contract from them for it, and they even provide a proper repository for apk to consume. I wish there were other options for certified JDK on Alpine of similar quality.

jerboaa commented 3 years ago

Java 11 Image sizes for reference

$ docker images
REPOSITORY                                   TAG                IMAGE ID      CREATED        SIZE
docker.io/adoptopenjdk/openjdk11             alpine-jre         6cf1fc1047fc  20 hours ago   149 MB
docker.io/adoptopenjdk/openjdk11             centos-jre         13dbb45d8dc0  20 hours ago   486 MB
docker.io/adoptopenjdk/openjdk11             ubuntu-jre         398ce73b3bf4  20 hours ago   249 MB

docker.io/adoptopenjdk/openjdk11             alpine             b6e96c767b1a  45 hours ago   343 MB
docker.io/adoptopenjdk/openjdk11             centos             2e830ca52a50  45 hours ago   679 MB
docker.io/adoptopenjdk/openjdk11             ubuntu             231c7df92d0b  44 hours ago   443 MB

I don't think we'd need Alpine images to get similar results as far as image size is concerned. Here is an experiment with ubi8-micro and a standard glibc build:

$ podman run --rm -ti ubi8-micro-java java -version
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7)
OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)
$ podman images ubi8-micro-java
REPOSITORY                 TAG     IMAGE ID      CREATED        SIZE
localhost/ubi8-micro-java  latest  b415bd3e991a  6 minutes ago  132 MB

Built using something like this:

$ cat buildah_adopt.sh
# Prepare the JRE:
JDK_URL="$(curl -s --head https://api.adoptium.net/v3/binary/latest/11/ga/linux/x64/jdk/hotspot/normal/adoptium | grep 'Location:' | sed 's/Location: //g'| tr -d '\r')"
SHA_SUM_URL="$JDK_URL.sha256.txt"
TMP_DIR=$(mktemp -d)
pushd $TMP_DIR
SHA_FILE=jdk.tar.gz.sha256sum
wget $JDK_URL $SHA_SUM_URL
sha256sum -c *.sha256.txt
mkdir jdk-11
BUILD_JDK="$TMP_DIR/jdk-11"
pushd $BUILD_JDK
tar --strip-components=1 -xf ../*.tar.gz
popd
# Choices are:
# - Specific module, like 'java.base'
# - Java SE, via module 'java.se'
# - All modules, via token 'ALL-MODULE-PATH'
# Run the jlink command
$BUILD_JDK/bin/jlink \
  --add-modules ALL-MODULE-PATH \
  --strip-debug \
  --no-man-pages \
  --no-header-files \
  --compress=2 \
  --output jre-11
JRE=$(pwd)/jre-11
du -sh $JRE
$JRE/bin/java -version
popd

# Build the runtime container based on UBI8 micro
microcontainer=$(buildah from docker.io/redhat/ubi8-micro)
buildah run --tty $microcontainer mkdir -p /opt/java
buildah add $microcontainer $JRE /opt/java/openjdk
buildah config --env 'JAVA_HOME=/opt/java/openjdk' $microcontainer
buildah config --env 'PATH=$JAVA_HOME/bin:$PATH' $microcontainer
micromount=$(buildah mount $microcontainer)
dnf --nogpgcheck --repoid=AppStream --repoid=BaseOS \
    --repofrompath='BaseOS,https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/x86_64/baseos/os' \
    --repofrompath='AppStream,https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/x86_64/appstream/os' install \
    --installroot $micromount \
    --releasever 8 \
    --setopt install_weak_deps=false \
    --nodocs -y \
    zlib
dnf clean all \
    --installroot $micromount
buildah umount $microcontainer
buildah run --tty $microcontainer java -version
buildah commit $microcontainer ubi8-micro-java

# Cleanup
rm -rf $TMP_DIR

$ buildah unshare bash ./buildah_adopt.sh
[...]
Getting image source signatures
Copying blob 5f70bf18a086 skipped: already exists  
Copying blob ea577ad08b91 skipped: already exists  
Copying blob ea35e4a18d6e done  
Copying config b415bd3e99 done  
Writing manifest to image destination
Storing signatures
b415bd3e991a9089bb0975ecde27eb1e348f1d2615655cad36847c49ce1567b4

karianna commented 3 years ago

Hi all,

TLDR Decision

The PMC met today and decided not to go ahead with the glibc based Alpine images.

Reasoning

The Alpine Committers and Maintainers have made it clear why glibc based Apline Images are a really bad idea (see comments above and/or at the alpine glibc build Pull Request at Docker official.

The Adoptium PMC believes that as part of distributing a secure and stable supply chain we should adhere to the guidelines from the Alpine maintainers.

Next Steps

We will therefore discard the alpine glibc build Pull Request from Docker official and remove the subsequent glibc alpine support from this repository.

A blog post explaining this decision and recommending alternatives (e.g. Smaller ubuntu/centos/ubi style images) will be made.

The Future --> Musl Builds

What we will do is push forward with our musl based alpine images investigations.

Java 16/17 - Those builds are doable today but we need to set up TCK infrastructure for those and see if we can make sure that meets compliance.
Java 8/11 - the various VM Engineers involved in the supporting companies (Azul, Microsoft, Red Hat, IBM, et al) will look to backporting the musl patches to Java 8 and 11. Timeline TBD.

srbala commented 3 years ago

Here in an alternate approach to build slim container package for UBI8, AlmaLinux and RockyLinux - EL8 series using muli-stage-build with existing docker or podman only. Possible solution for #54

# Prepare custom Java runtime 
FROM eclipse-temurin:11 as jre-build
RUN $JAVA_HOME/bin/jlink \
    --add-modules ALL-MODULE-PATH \
    --strip-debug \
    --no-man-pages \
    --no-header-files \
    --compress=2 \
    --output /javaruntime

#
# Prepare micro base image with minimal necessary dependency
# Add additional packages depends application need
#
# Choose one base image AlmaLinux, Rocky Linux or UBI
FROM almalinux:8.4 AS sys-build
# FROM rockylinux/rockylinux:8.4 AS sys-build
# FROM redhat/ubi8:8.4 AS sys-build
RUN mkdir -p /mnt/sys-root; \
    dnf install --installroot /mnt/sys-root --releasever 8 --setopt install_weak_deps=false --nodocs -y \
    coreutils-single \
    glibc-minimal-langpack \
#    tzdata openssl ca-certificates fontconfig \
#    curl gzip tar \
    zlib; \
    dnf --installroot /mnt/sys-root clean all; \
    rm -rf /mnt/sys-root/var/cache/* /mnt/sys-root/var/log/dnf* /mnt/sys-root/var/log/yum.*; \
    mkdir /mnt/sys-root/etc/yum.repos.d; \
    cp /etc/yum.repos.d/* /mnt/sys-root/etc/yum.repos.d/

COPY --from=jre-build /javaruntime /mnt/sys-root/opt/java/openjdk

FROM scratch
ENV JAVA_HOME=/opt/java/openjdk \
    PATH="/opt/java/openjdk/bin:${PATH}"

COPY --from=sys-build /mnt/sys-root/ /

CMD ["/bin/sh"]

Build size summary is given below. Image size is about 126MB adding extra packages (commented two lines in above script) to produdce a drop-in replacement image size is 162MB.

$ docker images | grep 'jdk11-temurin-slim\|jdk11-temurin-full'        
jdk11-temurin-full-alma      latest       905423585c09   48 seconds ago      162MB
jdk11-temurin-slim-alma      latest       7132c56b5d03   About an hour ago   126MB
jdk11-temurin-slim-rocky     latest       4b7e3e5aa75f   8 minutes ago       126MB
jdk11-temurin-slim-ubi       latest       304bc1d8dab0   6 minutes ago       126MB

srbala commented 3 years ago

Please make a note, jlink module strip utility support available from JDK 11 and above. Preparing slim package for JDK 8 might have fallback to old approach using slim-scripts.

karianna commented 3 years ago

As an FYI on slim images - Docker Hub official won't accept those so we won't be producing them directly. We'll likely provide guidance via tools/docs though so folks can roll their own. Stay tuned!

karianna commented 3 years ago

See #67

itzg commented 3 years ago

In the known issues of Docker 3.4.0 they report

On Apple Silicon in native arm64 containers, older versions of libssl in debian:buster, ubuntu:20.04 and centos:8 will segfault when connected to some TLS servers, for example curl https://dl.yarnpkg.com. The bug is fixed in newer versions of libssl in debian:bullseye, ubuntu:21.04 and fedora:35.

I would like to suggest that in addition to the LTS version of each respective distribution (Ubuntu and CentOS, I believe) that an "edge" variant be provided for the newest regular release, such as Ubuntu 21.04. With that said, I am still a huge proponent of the mainline/latest images being based on LTS, so I would not want to see a change to that philosophy.

Campano commented 2 years ago

Java 16/17 - Those builds are doable today but we need to set up TCK infrastructure for those and see if we can make sure that meets compliance.

Really intereseting thread indeed. Where can we follow the progress on that @karianna ?

karianna commented 2 years ago

@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 :-)

SourceNode commented 2 years ago

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:

$ docker pull eclipse-temurin:8-jre-alpine
8-jre-alpine: Pulling from library/eclipse-temurin
no matching manifest for linux/arm64/v8 in the manifest list entries

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!

karianna commented 2 years ago

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:
$ docker pull eclipse-temurin:8-jre-alpine
8-jre-alpine: Pulling from library/eclipse-temurin
no matching manifest for linux/arm64/v8 in the manifest list entries
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.

tianon commented 2 years ago

If you switch off the Alpine variant, arm64v8 is supported:

$ 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)

SourceNode commented 2 years ago

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".

vielmetti commented 2 years ago

@SourceNode #158 is a relevant issue.

SourceNode commented 2 years ago

Thank you for @vielmetti , sorry I did not see it before now.

sxa commented 2 years ago

@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.

adoptium / containers