Open 62mkv opened 4 years ago
The format of the Spring Boot layers index file can be seen here: https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/reference/htmlsingle/#executable-jar-war-index-files-layers
When layer information is provided there will be an entry Spring-Boot-Layers-Index: BOOT-INF/layers.idx
in the jar META-INF/MANIFEST.MF
manifest giving the location of the file.
You are right, layered Jars are not directly supported by this image, but I wonder how an s2i build on openshift could benefit from it, as the s2i scripts don't really have an influence on the image layering. If you are leveraging the s2i incremental build, then some content from the former image can be copied over to the actual build. For now this is just the local maven repository from ~/.m2/repository
. Of course the lib and resource layer from the dependencies could be copied over, too, but would this considerably speed up the build ? (as I expect those dependencies to be in the also-copied local Maven repository, so it would be "just" a local copy).
One could benefit from the layered approach when one has a more fine granular way of defining the layer of a container image (like directly with a Dockerfile), I don't see how this could be achieved with the S2I build mechanism.
But maybe I overlooked something ....
Sent from Mail.ru app for Android Wednesday, 20 May 2020, 09:03AM +03:00 from Roland Huß notifications@github.com :
You are right, layered Jars are not directly supported by this image, but I wonder how an s2i build on openshift could benefit from it, as the s2i scripts don't really have an influence on the image layering. If you are leveraging the s2i incremental build, then some content from the former image can be copied over to the actual build. For now this is just the local maven repository from ~/.m2/repository. Of course the lib and resource layer from the dependencies could be copied over, too, but would this considerably speed up the build ? (as I expect those dependencies to be in the also-copied local Maven repository, so it would be "just" a local copy). One could benefit from the layered approach when one has a more fine granular way of defining the layer of a container image (like directly with a Dockerfile), I don't see how this could be achieved with the S2I build mechanism. But maybe I overlooked something .... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or unsubscribe .
@62mkv got it, but I still not see how we can translate the layered jars to container image layers using s2i. 'would be happy if I'm wrong :)
is there any extended documentation on "how s2i-java" works? I've seen the build process ended up defining around 26-28 layers, some as small as several bytes long, but the last one (the one with the fat JAR, I assume) is like 400Mb. if I figured out how those layers are defined, maybe it would be more clear, where to raise this issue.
ok, I've raised that now: https://github.com/openshift/source-to-image/issues/1039
that one (https://github.com/openshift/source-to-image/issues/1039) has come to a stalemate. They say either it's s2i-java that does the trick, or it cannot be completed at all. May I ask @rhuss to look into that and if that's correct, then probably this could be closed (alas..)
Hi, I’m also very interested about this feature. at my company we use s2i build from binary and I’m thinking of implementing a save-artifact and assemble script that should be able to do incremental build with layered jars.
I am not sure if this is feasible or even is this the right project to raise this issue. but from what I understood thus far, it should be possible to get at least a hint.
Anyway, Spring Boot as of version 2.3.0 introduced concept of "layered JARs" (https://spring.io/blog/2020/01/27/creating-docker-images-with-spring-boot-2-3-0-m1#layered-jars) and this seems to be very relevant to
s2i-java
build flow on the OpenShift.From the docs and repository history, I don't have an impression that this is already supported by
s2i-java
, hence this feature request