[imtringued]

I also feel like Docker's multistage feature already solves the container size flaw.

>This tool also allows us to build containers without all the container development tools inside it (yum, GCC, secrets, etc). Basically, Buildah produces clean containers, which means the container can be much, much smaller.

With docker you basically have one stage where you load all the dev tools to build the application or library. Then you have a second stage where you merely copy your application and run it. I often have a Dockerfile that builds a java library which then merely copies the .jar file into an empty docker image. The end result is usually a docker image smaller than 10MB. Then I add this image to the dockerfile that actually needs the library by adding it as an empty multistage and as part of the last stage I just copy the files of the library image into the application image. This way you can "inherit" multiple docker library images into one application image.

[user5994461]

>>> The end result is usually a docker image smaller than 10MB.

You forgot to install the JVM to run the .jar, didn't you?

[devonkim]

A possible option for containers that all run JVM applications is to have a volume mount for all of them that points to an external filesystem containing the JAVA_HOME contents. This somewhat violates certain containerization principles but can help reduce some disk usage across dozens of containers on a host.

[IanCal]

You could base all the images on the same layer, then the disk space wouldn't be an issue, right?

[devonkim]

It is an advantage in specific situations when you can't rebuild every container or you want to try to selectively update containers without rebuilding them. You should try to update the running containers as a rule but having options is helpful from time to time. In a properly managed container infrastructure it should be faster to update the container image reference before resorting to tactics like this.

[IanCal]

It would be interesting to consider what it'd be like to swap out layers directly, instead of having to "rebuild" the final image.

Perhaps a hack for a free weekend.

[Spivak]

That would lead to a small image size because you would just apply the .jar to a base Java install but it doesn't do anything for the container size because they all will have their own JVM copy.

[IanCal]

I don't understand what you mean for the container size. If they share the same base layer it won't use more disk space to store than splitting it up, surely.

[riskable]

You're missing the fact that if they're all using the same layer (base image) for the JVM all the images will be deduplicated (well, CoW) so you could have a hundred different apps and they would only use the equivalent of a single image for the JVM (in terms of storage).

[imtringued]

The final stage usually uses the tomcat docker image or just the alpine java image and copies the jar/war files in there without building anything.