ORT Docker image size - is it possible to make it smaller?

[woznik]

Hello
Do you think it would be possible to decrease the size of the docker image (max to 2GB) - currently it's over 4GB
The image contains Android SDK - is this KIT (and maybe others) necessary for ORT to find the dependencies information?
The current size of a docker image has a huge impact on the duration of the scanning proces.
I use this docker image in a gitlab pipeline with a group of shared runners. Each time a user triggers an action to pull the image it takes at least 3-5 minutes to complete the download.
It impacts unnecessarly network and energy consumption.
If it is not possible I could try ti reorganize my use case

[sschuberth]

The image contains Android SDK - is this KIT (and maybe others) necessary for ORT to find the dependencies information?

When analyzing Android projects, unfortunately yes. While the Android plugin for Gradle is able to bootstrap several SDK components, the basic SDK needs to be installed even if just querying the dependencies of an Android project.

But that said, the stock Dockerfile is supposed to get you started easily and to showcase all ORT capabilities. If you do not need Android project analysis, you can easily trim the Dockerfile to your needs by omitting unwanted package managers / SDKs / frameworks.

But I agree there still is general room for improvement. I was thinking about using Alpine as a base image also for the final image, or look into ways to dynamically install the Android SDK only when Android projects are analyzed.

[woznik]

OK, I get it. Thank you for the explanation

[sschuberth]

Let's keep this open to track the ideas for still reducing the size that I mentioned before.

[mnonnenmacher]

@sschuberth We are currently investigating implementing bootstrapping for Pub/Flutter, because according to research by @zhernovs the Flutter installation takes about 2GB of data in the Docker image. This would make the analyzer slower for Pub/Flutter projects of course, but they are relatively rare and users who heavily rely on those could still make their own Docker file that includes Flutter. Any objections to that approach?

[sschuberth]

No objections. Just a question: As you know I was planning to remove bootstrapping for scanners. Would some of that logic still be valuable to keep in this context?

[zhernovs]

Here are some particular numbers related to this topic:

At the moment I did research uncompressed image from this Dockerfile weighs 3.91 GB. The biggest part of it is flutter: 1.5 GB. Built-in flutter/.pub-cache is 481 MB. So bootstrapping flutter will reduce docker image by almost 2 times.
I also did some local tests on HERE company's gitlab instance to verify how much benefits we will have with reduced-size image. In this experiment I've removed flutter (1.5 GB) with android-sdk (116 MB):

Compressed default image in gitlab registry: 1.78 GiB
Compressed image without flutter and android-sdk: 933.98 MiB

Time to start docker executor with default image: 1:29
Time to start docker executor with shrank image: 00:52

Time to download, unpack, prepare flutter on resulting image: 01:16

For future, the second tool by size that might be optimized/bootstrapped is go (327 MB).

Base image (adoptopenjdk:11-jre-hotspot-bionic 229 MB) could be replaced with something lighter (as an option adoptopenjdk/openjdk11:alpine-jre 149 MB), but this requires complete rewriting of Dockerfile if new image is based on Alpine (currently on Ubuntu).

[sschuberth]

FYI, bootstrapping Flutter was merged.

[sschuberth]

Maybe this also is yet another topic where Buildpacks as already mentioned here could help, also see https://github.com/paketo-buildpacks/gradle.

[sschuberth]

Note to myself: To reduce the Docker image size we might want to take a look at https://github.com/docker-slim/docker-slim.