Consider distroless java for base image #197
Comments
|
Tried creating an image with distroless Current Alpine + Zuul Java 8: 144MB I guess Java 11 is quite a bit bigger since there's been a lot of functionality added since Java 8 like modules, HTTP/2, and TLS 1.3 to name a few. Anyways will go ahead and send a PR don't necessarily have to accept it if the size difference is too much. |
|
the 144MiB is inclusive of zipkin itself. Are what you mentioned all-in?
|
|
Those are the sizes of the docker images using |
|
what's the advantage of this over the similarly not-so-slim openjdk slim image? is there any liability you forsee using a google image? |
|
Main advantage is it is still way slimmer than that one openjdk:8-slim 299MB There's no OS so no systemd and similar nonsense - container security scanning also works much better since most CVEs are systemd related The main liability I can see is how quickly they add support for a new JRE - supporting JRE11 took about half a year after release I think. The main reason for that though is they just use the debian packages - it took around that long for debian to backport JDK11 to stretch. |
|
gotcha.. I wonder though if we can make this the base image instead like before and squash it after removing the JDK part of it? openzipkin/docker-java@8cd5043#diff-3254677a7917c6c01f55212f86c57fbfL6 Currently our services only need JRE, and that's how we originally got some space back |
|
How about using jlink to make a minimal JRE for Zipkin in our Docker image? Seems like it can save a lot of space. Here's an article I found quickly (haven't tried it yet): https://qiita.com/h-r-k-matsumoto/items/1725fc587ce127671560 |
|
The distroless images only contain JRE so nothing special to remove JDK. So as it stands, I don't think we would need to make a special base image (or are you suggesting But it would make sense to have our own base image if we use jlink, which seems like a cool idea. I think we could automatically get a fully minimal JRE if we had a Java 9 modules definition, but if we have an idea of what modules are required could probably create it manually too. |
|
Well initial experimentation using a similar command to that article results in a huge JRE :( vs default |
|
That's probably docker-library/openjdk#217 |
|
Urgh nice find. Indeed, with that, just java.base,java.logging goes down to 31M. I'd leave it to @adriancole on whether it's a good idea at all to trim down the JVM, or which modules are needed (java.base,java.logging,java.sql come to mind but no clue if it's enough), as he probably has an idea of all the various usage of this base image :) |
|
imho if in either case we are using the distroless image, doing this in
parts could be helpful. Ex wave 1. see if all the things work with the
distroless variant. wave 2. see what works with modules etc.
I'm a little concerned about redundant layering, but on the other hand
someone running zipkin-aws is not also running zipkin-gcp and the base
distro at the same time (guess)
most of the size impact to me anyway is the zero->running of the
docker-compose files in this repo
…On Fri, Feb 15, 2019 at 3:07 PM Anuraag Agrawal ***@***.***> wrote:
Urgh nice find. Indeed, with that, just java.base,java.logging goes down
to 31M.
I'd leave it to @adriancole <https://github.com/adriancole> on whether
it's a good idea at all to trim down the JVM, or which modules are needed,
as he probably has an idea of all the various usage of this base image :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#197 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD61xc-MRD8VxOvNCkPdW5f5p-hkGAsks5vNlyzgaJpZM4a7HlD>
.
|
|
The other thing is I'd like to ensure however we go with this, that we are
still always using the same base zipkin uberjar. We will still have to
support 1.8 users and it would be weird to have different jars I think. I'm
not saying we would.
|
|
Yeah agree we would want to first try a different image and then try trimming it down. And I understand the compose issue now - I'd need to migrate the other folders in this repo to distroless too so they all share the same base image. I don't mind doing it if it seems worth trying. And yeah, I don't think we should create a java11-specific uberjar or anything, just update the JRE which still can have other benefits like TLS updates. So we just need to decide, do we think migrating to Java 11 is worth having a larger image for a little while until we potentially trim it down again. And whether we migrate all these Dockerfiles at the same time. @adriancole what do you think? |
|
So we just need to decide, do we think migrating to Java 11 is worth having a larger image for a little while until we potentially trim it down again. And whether we migrate all these Dockerfiles at the same time. @adriancole what do you think?
I can get behind this and support it when people moan :P I think the
current state of affairs is worse than image size.. that's my
rationale.
|
There's a java 11 version of distroless, which is a pretty slim docker image with JRE11. Might want to consider basing zipkin on it for better HTTP/2 support, and less gotchas thanks to using normal glibc.
GoogleContainerTools/distroless#285
The text was updated successfully, but these errors were encountered: