jx
jx copied to clipboard
jenkins-x
Support multi layer optimization of java application images
Summary
When creating docker images for Java applications in the current setup in Jenkins-X the application and all dependencies are all placed in one jar file, meaning it will be in one layer in the docker image.
This means that when new versions of the application are created the unchanged dependencies can't be reused.
It would be a great enhancement if the application code where put in a separate, top, layer so the lower layers could be reused: the time to create the image would be reduced, the push to the registry would be faster and the disk usage in both the docker engine and the docker registry would be reduced.
References
https://github.com/gclayburg/dockerPreparePlugin https://openliberty.io/blog/2018/07/02/creating-dual-layer-docker-images-for-spring-boot-apps.html
JIB is probably the solution with largest traction: https://github.com/GoogleContainerTools/jib
When using this for java build it essentially means skaffold is replaced with jib.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
As far as I can see it's as relevant as before. I'm not employed by Cloudbees though, so there might be things going on that I don't know about.
A word of caution: I'm not sure this is a good first issue; it involves changes in at least 2 repositories. This is what I think is needed:
Draft packs for building java applications need changes to pipelines.yaml (I think) and skaffold.yaml (Dockerfile can be removed). See https://github.com/GoogleContainerTools/skaffold/tree/master/examples/jib about the integration of skaffold and Jib. Also Jib needs to be configured in pom.xml / build.gradle. For this to be smooth for the user the addition of the Jib build plugin should preferably be done automatically by jx import. For maven this could be done in jx (method fixMaven in pkg/cmd/importcmd/import.go) for gradle I don't know of a any existing mechanism. For the gradle case you could at least change the quickstarts that use gradle.
I would start with the maven-java11 draft pack so you can use of the automatic update of pom.xml and also avoid the need to change the default jvm flags since the memory settings of java 11 are sensible for docker by default.
It would probably be a good idea to discuss this on Slack or at the office hours since it's a fairly big change.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten
This is a cool idea and could be put in place for more than just our java packs.
This could be achieved by just using it within a quickstart demoing how to do this.
I think this could be achieved already, but if we achieve this, I'd expect some more documentation to be created around the repository.
We could add this to our GSOC proposal if there is still interest here?
Yes, putting it in quickstarts would certainly be better than nothing. That ought to be suitable for GSOC. For java the spring boot approach would be simplest: https://spring.io/guides/gs/spring-boot-docker/ A reason for that is that you need credentials for the registries in the different cloud environment. This is already solved for the build-container-build step (image gcr.io/kaniko-project/executor:v1.6.0-debug), but not for the build-mvn-deploy step (image maven:3.6-openjdk-8-slim) that jib would be executed in. So the spring-boot:build-image goal (or equivalent for gradle) should not be used.
It would be preferable to add the multi layer optimization on import of java projects in general, but it would also be tricky.