Background Link to heading
I’m a fan of using buildpacks. I’ve been using and updating the paketo-arm64 repository started by Daniel Mikusa. With Spring Boot 3 going GA, very soon, more people are wanting to use buildpacks with their M1 machines. I feel pressure, in a great way, to get a new version released that includes the latest version of GraalVM.
Because I’m not doing this regularly, I forget the steps that I take to create a new build. So this post, is really a reminder-to-self, but hopefully it helps someone else also.
You can follow along with this on M1,Raspberry Pi, or a free-tier ARM64 instance from Oracle.
Prerequisite Link to heading
I’ve been setting up a temporary ARM64 machine on Oracle Cloud for ARM64/aarch64 builds. The repository I use is here. I should probably talk about that in another post, also.
My first step was to deploy that machine, so it can be used to build the builder! Once I got the machine up and connected to my repository, I was ready to update the code.
Make changes Link to heading
First I just made changes to the versions in my GitHub workflow. That worked and pushed out a new image, but it wasn’t enough.
I had to re-read the workflow to understand what I was missing.
For each of the files in the arm64-toml of the repository I needed to update to the latest versions.
This is a tedious, and currently manual, process that requires copy, paste, merge and then creating sha256 values.
For these versions, it was extra messy, because naming conventions changed since my last release.
In some places arm64 was replaced with aarch64 as one example.
Additionally, some dependencies had even more releases, and I decided to go with the full option when it was available.
The last real time-suck was the sha values.
In the GitHub releases, the sha values are provided as sha1sum values.
In the builder metadata, it requires sha256 values.
Since I couldn’t find sha256 values published anywhere, I had to download the dependencies and calculate the values manually.
For each dependency update, curl then shasum, which can be error prone.
curl -L https://github.com/bell-sw/Liberica/releases/download/8u352+8/bellsoft-jdk8u352+8-linux-aarch64.tar.gz -O
shasum -a 256 bellsoft-jdk8u352+8-linux-aarch64.tar.gz
Hopefully, this post and the small updates I made to the README.md will remind me next time.
I should probably figure out a way to automate some of that.
Maybe a CLI?
Create an application image Link to heading
Create a Spring Boot 3 application with web and actuator which is enough for a simple test.
# Create a Spring Boot 3 application
curl https://start.spring.io/starter.tgz -d dependencies=web,actuator -d javaVersion=17 -d bootVersion=3.0.0-SNAPSHOT -d type=maven-project | tar -xzf -
In the pom.xml replace this:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
with this:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<builder>dashaun/java-native-builder-arm64:7.37.0</builder>
</image>
</configuration>
</plugin>
</plugins>
</build>
Build an image using the image builder that we have created and configured.
./mvnw -Pnative spring-boot:build-image
Run and test the image Link to heading
Run the OCI image with docker to start up the server.
It should start quickly!
# Forward the prt, run in the background, but see the startup time
docker run -p 8080:8080 demo:0.0.1-SNAPSHOT &
# Check the endpoint to validate
http :8080/actuator/health
Finally Link to heading
Because I’m done, and moved builder version 7.37.0 to prod, I also cleaned up my terraform deployment.
Another huge “Thanks” to Daniel Mikusa for all of his help.