containers
containers copied to clipboard
adoptium
Support Debian base images (Java 8, 11, 17)
See https://hub.docker.com/_/eclipse-temurin for official support and guidance on how to use our builds with other base images (such as Debian).
Is there any chance to have these kind of base images? Right now no Debian-based image is available (or I am just unaware of), but base from Ubuntu (which I prefer not to use for several reasons).
Is this decision final to not provide these?
@FibreFoX - Unfortunately that is correct as we prefer to support the official base distros that DockerHub supports. It's pretty easy to create your own via the guides: https://hub.docker.com/_/eclipse-temurin
@karianna Not wanting to stress this old issue too much ... but Debian itself is an official base distro at DockerHub ... https://hub.docker.com/_/debian
Am I missing something?
@gdams to look when he gets back - I'm not close enough to it but I know we maxed out our supported list over there so to speak.
Hello, I am one of the co-maintainers of the official Docker Clojure images. We recently moved our upstream images from the old openjdk ones to these eclipse-temurin images. I want to make a case for using Debian base images here:
Ubuntu is less appropriate for Docker images than Debian due to their tendency to move packages from APT / DEB to snap. These snap packages are not easily installable in Docker containers because they need a daemon running. One example I recently ran into is the chromium-browser package. I use this in Docker containers to run headless ClojureScript tests. However, I can no longer easily do apt-get install -y chromium-browser because that executable just tells me I have to use the snap package now (which I can't easily do).
Debian is a much nicer distro for use in Docker containers for this reason alone. If this can still be considered it would be very helpful. Thank you!
@cap10morgan thanks for your comments here (and maintaining the clojure images). I'll report this back to the program management committee and see if there's any further updates. Just a thought but could the clojure images use multistage builds to copy the JDK into a debian base image? e.g:
FROM debian
ENV JAVA_HOME=/opt/java/openjdk
COPY --from=eclipse-temurin:17 $JAVA_HOME $JAVA_HOME
ENV PATH="${JAVA_HOME}/bin:${PATH}"
@gdams Yeah, potentially. I'm looking into it. Thanks for your attention to this!
@gdams Why are you offering this "easy way" and not provide a base debian image yourself? Seems to be no problem, and as the debian image is some official docker image, what is the problem to add debian to your images?
Using a self-build image is no good solution, especially for usage as build-images in tools like GitLab build pipelines. So from my point of view, this self-build image brings more problems than solutions. In addition, having a real debian based image would make it more a drop-in replacement for the previous openjdk ones.
@FibreFoX taking in too many OSes can take overhand and should be carefully considered IMO. If they are supported, they do have to be supported, right?
Just see the absurd amount here in the former project: https://hub.docker.com/r/adoptopenjdk/openjdk11
I do see a point for debian, but adding more to the scope of Adoptium also generates more efforts to make sure things keep working across all OS-variants.
@DRoppelt As Ubuntu is based on Debian .... do you expect this to be that kind of a trouble?
As part of "the community", I would prefer Debian-based images over Ubuntu-based images. The point mentioned by @cap10morgan regarding snap-packages, for me, is pretty big and crucial to specificly add Debian as an supported image.
@FibreFoX I use Ubuntu based images for build agents and alpine for runtime. I have no experience with the difference between Debian and Ubuntu.
I don't think it is about whether or not they can but if they should. @gdams said they would bring it up in a committee. Resources are limited so I think that's fair.
If I were you, I would submit a PR to this repo. It should be fairly straight forward to add besides Ubuntu. Maybe that helps accelerating the decision?
Another advantage of Debian is, that you don't need the DEBIAN_FRONTEND=noninteractive hack. Debian works very well in noninteractive environments while Ubuntu has some troubles when installing locales or timezones.
Is anyone looking at Debian-based images to be used as-is, without them having to write a Dockerfile at all? If yes, what is the use case?
I do assume that everyone is writing a Dockerfile anyways, but I'd love to hear cases where people are not defining downstream images of their own.
Is anyone looking at Debian-based images to be used as-is, without them having to write a Dockerfile at all? If yes, what is the use case?
I do assume that everyone is writing a Dockerfile anyways, but I'd love to hear cases where people are not defining downstream images of their own.
For downstream-from-this-but-upstream-from-users images like clojure, it's very inconvenient for them to have to start from this image. So we (the clojure image maintainers) provide images where we pull in the clojure bits from these Ubuntu-based images into Debian-based upstreams. Which is workable but not ideal. More work repeated for every such intermediate image type (there are a few on the JVM).
And ultimately this is about the best distro to base a Docker image on, regardless of use case. Ubuntu has fundamental shortcomings in this area with no real benefits. As has been outlined above.
@cap10morgan I don't want to go into the "Debian vs Ubuntu" matter right now.
My question is whether a user who wants to see a Debian image, wants that because they are not writing a Dockerfile at all and instead are using as-is. If so, then yes it makes sense to ask for a Debian-based image. Otherwise, I'd like to understand the challenge in adding two lines into their own Dockerfile to pull the JDK binary from another image.
@cap10morgan I don't want to go into the "Debian vs Ubuntu" matter right now.
My question is whether a user who wants to see a Debian image, wants that because they are not writing a
Dockerfileat all and instead are using as-is. If so, then yes it makes sense to ask for a Debian-based image. Otherwise, I'd like to understand the challenge in adding two lines into their ownDockerfileto pull the JDK binary from another image.
And I've responded already to that with whole categories of use cases where it's a lot more than "adding two lines" and regardless of whether or not users are writing their own Dockerfiles this still makes sense to do. But it also seems weird to willfully ignore the primary reason to make a switch because it doesn't interest you. :/
And yet, I can't see the challenge in writing this:
FROM debian
ENV JAVA_HOME=/opt/java/openjdk
COPY --from=eclipse-temurin:17 $JAVA_HOME $JAVA_HOME
ENV PATH="${JAVA_HOME}/bin:${PATH}"
ADD app.jar
CMD ["java", "-jar", "app.jar"]
Instead of this:
FROM eclipse-temurin:17-debian
ADD app.jar
CMD ["java", "-jar", "app.jar"]
If this project adds Debian-based images, (or worse replaces Ubuntu with Debian), sooner or later, someone will want a Slackware base image. Or Arch Linux. Or any other Linux distribution.
IMO pre-built container images are meant to be conveniences, not fully baked products. Publishing images for every little variation is time-consuming, error-prone, security risk, adds little value to the broader set of users, and takes a lot of time from the very few maintainers around.
@brunoborges It seems like you're not engaging with the merits of the discussion. If you were it would be pretty clear that this is not about "my favorite distro" at all. 🤷🏼♂️
Another thing why debian based images are important: build servers
When using GitLab CI runners, you can specify the base image you want to use for running your commands. It is not realistic to build a docker image to be used as part of the build pipeline.
I have to admit, I wanted to provide a PR, but lacked time to do so. I'll try to find some time to create that PR this week.
@FibreFoX I have submitted a PR in the past (https://github.com/adoptium/containers/pull/313), it was not about the lack of someone providing the code for the support, but a PMC decision.
Just to add another reason: Debian is available for platforms amd64, arm32v5, arm32v7, arm64v8, i386, mips64le, ppc64le, s390x while Ubuntu is only available for amd64, arm32v7, arm64v8, ppc64le, s390x.
Just to add another reason: Debian is available for platforms
amd64, arm32v5, arm32v7, arm64v8, i386, mips64le, ppc64le, s390xwhile Ubuntu is only available foramd64, arm32v7, arm64v8, ppc64le, s390x.
That's true, but adoptium does not support any more than the five Ubuntu ones and that's not likely to change any time soon. (Although I'm hoping riscv64 will be next on the list, but there are versions of Ubuntu for that architecture too)
This topic was discussed at the Adoptium Project Management Committee meeting on April 26th.
We debated the benefits/disadvantages to our users, and costs to the project of providing Debian base OS images. We remain of the option that providing clear instructions for users to use Temurin with a base OS of their choice remains the most sustainable way of proceeding.
Each time we add a new base OS container image incurs overhead to the project in terms of maintenance, testing, and support. As pointed out by Dennis (@DRoppelt) above, this soon became unmanageable at AdoptOpenJDK where we has a different policy and produced many variants.
Bruno (@brunoborges) shows clearly how we would expect users to build an image with their preferred base OS, based on those we publish through Dockerhub.
Without compelling evidence of an important use case where this won't work, the PMC agreed to continue to provide only the images that are in plan and will, to the best of our ability, support the use of Temurin used in a multi-stage build into a compatible base OS.
This is very disappointing, especially because it is no drop-in replacement anymore!
@FibreFoX can you describe a bit more on what you mean by "drop-in replacement"?