Creating Image using BuildPacks - Spring Boot 2.3.0

[arpan2501]

Hi

I am creating image using Buildpacks with Spring 2.3.0 Release on Windows machine.

I am facing a below error in the logs and does the builder image changed from docker.io/cloudfoundry to gcr.io/paketo-buildpacks or it was changed in recent release as I was following the blog.

Previously I was using JIB and with 2.3.0 upgrade now I am exploring Buildpacks.

[INFO] --- spring-boot-maven-plugin:2.3.0.RELEASE:build-image (default-cli) @ SchedulePolling ---
[INFO] Building image 'docker.io/library/SchedulePolling:1.2'
[INFO]
[INFO]  > Pulling builder image 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 100%
[INFO]  > Pulled builder image 'gcr.io/paketo-buildpacks/builder@sha256:7996dd44d157f656bdea4f1063760ad8d4eae2dd41465f7fe6bf720f5b25ca4d'
[INFO]  > Pulling run image 'gcr.io/paketo-buildpacks/run:base-cnb' 100%
[INFO]  > Pulled run image 'gcr.io/paketo-buildpacks/run@sha256:15bccd9803f63b20a38a6834821a74d9c3949eb475cf759446047dc9586ca2a9'
[INFO]  > Executing lifecycle version v0.7.5
[INFO]  > Using build cache volume 'pack-cache-7a681574bdee.build'
[INFO]
[INFO]  > Running creator
[INFO]     [creator]     ERROR: failed to all tags must have the same registry as the exported image: could not parse reference: docker.io/library/SchedulePolling:1.2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  18.263 s
[INFO] Finished at: 2020-05-18T02:00:11+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.3.0.RELEASE:build-image (default-cli) on project SchedulePolling: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:2.3.0.RELEASE:build-image failed: Builder lifecycle 'creator' failed with status code 3 -> [Help 1]

[scottfrederick]

Previously I was using JIB and with 2.3.0 upgrade now I am exploring Buildpacks.

Are you saying that the image 'docker.io/library/SchedulePolling:1.2' exists in Docker having previously been created with JIB, and now you're trying to update the image with spring-boot:build-image? If that's the case, there's no guarantee that kind of scenario will work.

If that's not the case, please provide more details on the steps that we'd need to re-create the issue.

[arpan2501]

I didn't create this image with JIB, for previous projects I was using JIB and for this I started exploring buildpacks.

It got fixed by changing the build image name in all lower case - docker.io/library/schedule-polling:1.3 and the image was built successfully.

Thanks a lot as I tried downloading a new demo project and for it the image was built so I compared and found the difference in casing and changed it,

[scottfrederick]

The source of the error is the CNB builder that is being invoked by Spring Boot. The builder does not accept upper-case characters in the image name. You'll get a similar error when trying to use an image name like this with the pack CLI:

$ pack build docker.io/library/DemoProject:1.0 --builder gcr.io/paketo-buildpacks/builder:base-platform-api-0.3 --path build/libs/demo-0.0.1-SNAPSHOT.jar
ERROR: invalid image name 'docker.io/library/DemoProject:1.0': could not parse reference: docker.io/library/DemoProject:1.0

I've opened an issue in the CNB project to see if the error message can be improved.

I've also created #21495 to see if there's anything Spring Boot should do to improve the user experience.

[arpan2501]

@scottfrederick - Hi, is there a way we can specify the -Xms and -Xmx configurations using Buildpacks and enable GC logging too. I am thinking my Heap is not getting cleared and memory consumption of Pod is increasing rapidly over time (like 100 MB in one day).
Any Blog or sample file you can point will be much appreciated as I am not able to find it.

[philwebb]

@arpan2501 I know the older buildpack used to support JAVA_OPTS but I can't find documentation for the new one.

Perhaps @nebhale can help.

[arpan2501]

EDIT
I have tried the thread count-25 and it works, the Heap size and GC also works.

I am seeing the initial RSS being 155M and moving up to 192M within 9 hours.

The app has 2 cron job and spring jdbc with hikari cp of pool size - 5. Not sure where the memory is leaking out as on local when I run and use JProfiler the heap is continuously getting cleared up but when containerise it the memory goes on increasing.

Got the logs as well now-

[4799.878s][info][gc] GC(307) Pause Young (Allocation Failure) 28M->19M(30M) 1.001ms 

[4812.453s][info][gc] GC(308) Pause Young (Allocation Failure) 28M->19M(30M) 1.470ms

[4812.460s][info][gc] GC(309) Pause Young (Allocation Failure) 28M->20M(30M) 1.193ms

Request - It would be GREAT if we get the default CPU and RAM parameters to be set to run the containers when we do mvn spring-boot:build-image.

[nebhale]

$JAVA_OPTS is simply honored if you set it. So in docker --env JAVA_OPTS="..." and in Kubernetes with an env: block. The memory calculator then takes any values a user sets into account before attempting its calculation. The very first line of output when one of the CNB-based images starts up will be any additional properties set by the calculator.

Container memory limit unset. Configuring JVM for 1G container.
Calculated JVM Memory Configuration: -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=87842K -XX:ReservedCodeCacheSize=240M -Xss1M -Xmx448733K (Head Room: 0%, Loaded Class Count: 13095, Thread Count: 250, Total Memory: 1073741824)

@arpan2501 Can you please check your logs and ensure that you are getting a memory configuration that you expect?

[arpan2501]

@nebhale yes I can see and memory is getting set as expected. But it would be great if we can have a blog or link where we can find the parameters to tune the JVM.

[nebhale]

@arpan2501 I'm interested to hear what exactly you'd think that would look like. We do document each buildpack's configuration both in their README and in their build output:

The command that we run makes reference to ${JAVA_OPTS} and maybe we could be a bit more overt about that.

But the general idea is that you can set any JVM flag you'd like and we'll back off (like Boot does) when you've overridden our opinions. We don't want to be in the business of documenting every JVM flag, but at the same time, it was clearly confusing to you so what could we have done to make the "any JVM flag" idea more obvious?