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
Raspberry Pi, or a free-tier
ARM64 instance from Oracle.
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.
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,
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
Create a Spring Boot 3 application with
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>
<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
Run the OCI image with
docker to start up the server. It should start quickly!
# Forward the part, 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 http :8080/actuator/health
Because I’m done, and moved builder version 7.37.0 to prod, I also cleaned up my
Another huge “Thanks” to Daniel Mikusa for all of his help.
Top comments (0)