spring-boot
spring-boot copied to clipboard
Document Buildpacks CDS and Spring AOT support
As discussed with @philwebb today, it would be nice if Spring Boot 3.3 documentation could make CDS and Spring AOT Buildpacks support, which has just been deployed to production, more discoverable. The various configurations are now documented in https://github.com/paketo-buildpacks/spring-boot README, but from a Spring Boot POV my proposal would be to:
- Document that (at least) in the efficient deployment section
- Link the official CDS documentation
- Mention that CDS can be enabled via
BP_JVM_CDS_ENABLED=true
. In practice, that means Buildpacks will perform a training run, create a related.jsa
file with the application classes cached, and use it by default when running the container. - Document that
CDS_TRAINING_JAVA_TOOL_OPTIONS
can be used to fine tune the training run configuration (typical use case is to avoid early DB interactions, related documentation will be available in https://github.com/spring-projects/spring-lifecycle-smoke-tests, I plan to work on that). - Mention that Spring AOT can also be enabled via
BP_SPRING_AOT_ENABLED=true
. That requires AOT processing upfront (already documented) and will enable the AOT mode when running the container. - Link https://github.com/paketo-buildpacks/spring-boot for more details (especially about the
BPL*
configs we don't have to document on Spring Boot side).
If you do tests to ensure it works as expected, be aware that for now it is expected to work only on x86. aarch64 support should be fixed (when leveraging the beta multi arch support) before Spring Boot 3.3.0 release (ongoing related work is happening).
just a (arm64) note : spring-boot
Maven and Gradle plugins use, by default,
- the builders named
paketobuildpacks/builder-jammy-base:latest
orpaketobuildpacks/builder-jammy-tiny:latest
when native is activated - none of them support dual arch (yet) ❌ - the (composite )buildpacks named
paketobuildpacks/java:latest
or, when native is enabled,paketobuildpacks/java-native-image:latest
both of them are published as dual arch now ✅
To benefit from dual arch support, the users have to specify an alternative builder: paketobuildpacks/builder-jammy-buildpackless-tiny:latest
which is dual arch - otherwise, the arm64 path is not complete and won't allow users to use Java buildpacks arm64 flavor.
Since this builder is buildpackless
users have to manually specify the buildpacks they need.
Maven:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions> <!-- not necessary for arm64, but better take good habits now-->
<execution>
<id>process-aot</id>
<goals>
<goal>process-aot</goal>
</goals>
</execution>
</executions>
<configuration>
<image>
<env> <!-- not necessary for arm64, but better take good habits now-->
<BP_JVM_CDS_ENABLED>true</BP_JVM_CDS_ENABLED>
<BP_SPRING_AOT_ENABLED>true</BP_SPRING_AOT_ENABLED>
</env>
<buildpacks>
<buildpack>paketobuildpacks/java</buildpack>
</buildpacks>
<builder>paketobuildpacks/builder-jammy-buildpackless-tiny</builder>
</image>
</configuration>
</plugin>
Gradle:
plugins {
[...]
id("org.graalvm.buildtools.native") version "0.10.1" // not necessary for arm64, but better take good habits now
}
[...]
tasks.bootBuildImage {
builder.set("paketobuildpacks/builder-jammy-buildpackless-tiny")
buildpacks.add("gcr.io/paketo-buildpacks/java")
environment.put("BP_SPRING_AOT_ENABLED","true") // not necessary for arm64, but better take good habits now
environment.put("BP_JVM_CDS_ENABLED","true") // not necessary for arm64, but better take good habits now
}
There is no scheduled date when the default builders paketobuildpacks/builder-jammy-base:latest
and paketobuildpacks/builder-jammy-tiny:latest
will be published as dual arch(the best bet is to wait for the Ubuntu Noble based builders that will all be dual arch from day one and should arrive soon, but not for SB 3.3)
I have began to document the configuration customizations required to avoid early DB interactions cc @christophstrobl:
I am now working on adding CDS automated tests to https://github.com/spring-projects/spring-lifecycle-smoke-tests, so maybe the current CDS documentation can link https://github.com/spring-projects/spring-lifecycle-smoke-tests/blob/main/STATUS.adoc like what is done for CRaC.