ci.docker icon indicating copy to clipboard operation
ci.docker copied to clipboard

Image size for production use

Open faandg opened this issue 5 years ago • 7 comments

Hi,

We are using 20.0.0.7-kernel-java8-openj9-ubi to build container images. Using the image means adding an application, installing features and adding some configuration. Our production containers are around ~850MB in size which is quite large for an image.

Using dive we looked at the breakdown of such an image:

image

We were wondering if any of these components can be stripped of unnecessary parts? Doing this ourselves would probably mean forfeiting support?

Best regards.

faandg avatar Aug 21 '20 09:08 faandg

Thanks @faandg - this is a great topic, and having a visualization of your data really helps.

The UBI 8 Standard (OS) and AdoptOpenJDK 8 (Java) layers are as expected. There is a small footprint OS that we have used in the past (UBI 8 min), which last I checked reduced the image by about 120 MB - but, it came with the price that not all of the tools needed for proper production serviceability were there, and you had to use microdnf instead of yum. That is always something that can be discussed though.

Can you drill down into your output? I wonder if the 137 MB is coming from the class cache. Did you run configure.sh in your application Dockerfile?

I am also curious about your application being 90 MB - is that accurate?

cc @NottyCode @vijaysun-omr

arthurdm avatar Aug 21 '20 13:08 arthurdm

Hi @arthurdm, you are correct in assuming the output folder contains mostly class cache:

image

Yes, we use configure.sh in our Dockerfile and we see the application server restarting several times to build up the SCC. We know we can disable it using ARG OPENJ9_SCC=false but in this case we prefer using it to reduce the overall memory footprint.

Concerning the application - it is the first of 60 applications we are moving from WebSphere ND to Liberty on OCP and it is not quite split into microservices yet :) It is an EAR with several components and libraries. The size you are seeing is the packaged EAR and the expanded libs:

image We know we can still further reduce this but it's still a work in progress.

We found the kernel-ubi-min image during our first searches among the WebSphere Liberty tags and we did have some interest in using them. When you say "it came with the price that not all of the tools needed for proper production serviceability were there", could you elaborate which tools were missing and/or which task for serviceability wouldn't be available?

faandg avatar Aug 24 '20 09:08 faandg

Hey @faandg - sorry for the delay. For UBI 7 (which we were using at the time), the minimal image didn't even have things like ps. But some things changed in UBI 8, and we have been getting a lot of requests for a smaller images, so a min tag is possible.

If we were to support a UBI 8 min image, what Java layer would you be interested in? I am thinking about AdoptOpenJDK 11 + OpenJ9.

arthurdm avatar Sep 10 '20 20:09 arthurdm

No problem @arthurdm. We would be interested in both AdoptOpenJDK 8 + OpenJ9 and AdoptOpenJDK 11 + OpenJ9. Preferably this ubi-min image would have the Liberty kernel layer since we care about the size of the image.

Most of our large enterprise customers have not been using JDK11 yet, some only partially migrated/tested or only for new development projects. Some simply say they have no reason to change, until they do :)

faandg avatar Sep 11 '20 19:09 faandg

let's consider this one Leo - for both OL and WL.

arthurdm avatar Oct 16 '20 20:10 arthurdm

Is there any news about this? I'm very interested in every possibility to shrink the image size.

LDL-GH avatar May 28 '21 11:05 LDL-GH

@LDL-GH Adding ubi-min based images is in our roadmap. We completed the initial investigation and planning to start the work soon.

leochr avatar Jun 01 '21 19:06 leochr