DEV Community: DaShaun

Multi-Architecture Spring OCI from anywhere with Paketo

DaShaun — Tue, 17 Dec 2024 17:33:00 +0000

Multi-Architecture Spring OCI from anywhere with Paketo

My favorite feature of Spring Boot 3.4.0 is the adoption of multi-architecture buildpacks.
This feature empowers you to construct native images and traditional JVM-based applications for both AMD64 and ARM64, from a unified build process.
The fact that OCI images will also be smaller because of the new default buildpack is a bonus.

Emotionally Invested

I've been building native images for ARM64 since 2021, because I'm a Raspberry Pi enthusiast and passionate about Spring Boot.
Since that time, I've created dozens of solutions, to put production-ready, enterprise-grade, Spring Boot on Raspberry Pi ARM64 devices with only 512MB of RAM.
I no longer have to support my own solution.

Getting Started

Prerequisites:

At least Java 17
Docker

Docker Desktop Configuration

Docker Desktop comes with built-in QEMU support for multi-architecture builds. However, if you need to install QEMU manually, you have two options:

Option 1: Using tonistiigi/binfmt

# Install QEMU support for all architectures
docker run --privileged --rm tonistiigi/binfmt --install all

This command was found here: https://docs.docker.com/build/building/multi-platform/

Option 2: Using multiarch/qemu-user-static

# Install and configure QEMU
docker run --privileged --rm multiarch/qemu-user-static --reset -p yes

More information can be found here: https://github.com/multiarch/qemu-user-static

Spring Boot 3.4.0 application

First, let's create a new Spring Boot application:

mkdir mydemo
cd mydemo
curl https://start.spring.io/starter.tgz -d dependencies=web,actuator -d type=maven-project | tar -xvzf -

You could also use https://start.spring.io

Create a multi-architecture OCI Image

Here's the step-by-step process to build and publish multi-architecture images:

# Build ARM64 image
./mvnw spring-boot:build-image -Dspring-boot.build-image.imagePlatform=linux/arm64 -Dspring-boot.build-image.imageName=dashaun/blog-3-4-0:arm64
docker push dashaun/blog-3-4-0:arm64

# Build AMD64 image
./mvnw spring-boot:build-image -Dspring-boot.build-image.imagePlatform=linux/amd64 -Dspring-boot.build-image.imageName=dashaun/blog-3-4-0:amd64
docker push dashaun/blog-3-4-0:amd64

# Create and push multi-architecture manifest
docker manifest create dashaun/blog-3-4-0:multiarch --amend dashaun/blog-3-4-0:arm64 --amend dashaun/blog-3-4-0:amd64
docker manifest push dashaun/blog-3-4-0:multiarch

Inspect

Inspect the multi-architecture manifest:

docker manifest inspect dashaun/blog-3-4-0:multiarch

Inspect the manifest, results below.

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
  "manifests": [
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 2407,
      "digest": "sha256:96d95eed9308f86a8055156913ed8710c25917bdf0389bd6d5cf2ab0a79c77fc",
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "size": 2406,
      "digest": "sha256:4c42eebe412f56a03d840d2660b9defde3820ce1c5e510ffba0067be0ae11c8e",
      "platform": {
        "architecture": "arm64",
        "os": "linux"
      }
    }
  ]
}

The manifest shows both platforms linux/amd64 and linux\arm64

Looking at the Docker Hub tags Digest sections, notice that the sha values for the arm64 and amd64 tags match the multiarch tag's values.

The new default buildpack, builder-jammy-java-tiny also results in much smaller images. Both of the images we created here are under 275mb.
Switching to Spring Boot 3.3.6 and the previous default buildpack paketobuildpacks/builder-jammy-base results in a ~350mb image.

Building Native Images

The process for building native images is similar, with the addition of GraalVM support:

mkdir my-native-demo
cd my-native-demo
curl https://start.spring.io/starter.tgz -d dependencies=web,actuator,native -d type=maven-project | tar -xvzf -

You could also use https://start.spring.io

Building Multi-Architecture Native Images

When the buildpack see's the native-maven-plugin in the project, it creates native images with GraalVM. Our steps won't change, we will just use different tags.

# Build ARM64 native image
./mvnw spring-boot:build-image -Dspring-boot.build-image.imagePlatform=linux/arm64 -Dspring-boot.build-image.imageName=dashaun/blog-3-4-0:native-arm64
docker push dashaun/blog-3-4-0:native-arm64

#Build AMD64 native image
./mvnw spring-boot:build-image -Dspring-boot.build-image.imagePlatform=linux/amd64 -Dspring-boot.build-image.imageName=dashaun/blog-3-4-0:native-amd64
docker push dashaun/blog-3-4-0:native-amd64

# Create and push multi-architecture manifest
docker manifest create dashaun/blog-3-4-0:native-multiarch --amend dashaun/blog-3-4-0:native-arm64 --amend dashaun/blog-3-4-0:native-amd64
docker manifest push dashaun/blog-3-4-0:native-multiarch

Inspect Native

docker manifest inspect dashaun/blog-3-4-0:native-multiarch

Inspect the manifest, results below.

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2407,
         "digest": "sha256:70311015a28ff9ebbaa0ef0552e91bd85d2220716b69a8444ecf18ae542fa3f1",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2406,
         "digest": "sha256:4b9243d946a61f5fd8c9762f9e8a5ef107ba5a51a3679faa54b5a3cd96e4147c",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      }
   ]
}

The manifest shows both platforms linux/amd64 and linux/arm64

Take a look at these image sizes!

dashaun/blog-3-3-6                         latest           0e61fed5cf4a   44 years ago   348MB
dashaun/blog-3-4-0                         amd64            6ce61c588eba   44 years ago   268MB
dashaun/blog-3-4-0                         native-amd64     9f63e381e26c   44 years ago   117MB
dashaun/blog-3-4-0                         native-arm64     7a9b08bf964a   44 years ago   111MB
dashaun/blog-3-4-0                         arm64            0d07d6f15c86   44 years ago   259MB

I did this experiment on MacOS with ARM64 (M3 chip), but these exact same steps can be used on either ARM64 or AMD64 machines.

Conclusion

Spring Boot 3.4.0's multi-architecture support with Paketo buildpacks revolutionizes how we build and deploy applications across different architectures. Whether you're targeting cloud platforms or edge devices like Raspberry Pi, you can now build and deploy with confidence.

The combination of:

Multi-architecture support
Smaller image sizes
Native image capabilities
Simplified build process

Makes Spring Boot 3.4.0 a compelling choice for modern cloud-native and edge-native applications.

Keep Learning

Spring Health Assessment Report

DaShaun — Sat, 17 Feb 2024 03:11:50 +0000

Spring Boot 3.0.0 was released 450 days ago. Helping people upgrade, and enjoy all the amazing benefits, has been one of my passions for about 450 days. I'm a Spring Developer Advocate and I love my job.

It's a passion really. Thomas Schuehly gets it.

At SpringOne 2023 in Las Vegas, my friend, Joachim Pasquali, over at Fiserv, shared a story that I'll not soon forget. The process of upgrading and patching, doesn't have to be a painful process. On that day, his flagship product, was on the latest and greatest version of Spring Boot. Watch the clip that gave me all the feels here.

I want you to know about some tools and techniques that can help you upgrade your Spring Boot projects with more joy, frequently, and safely.

First things first, let's talk about the challenges. Outdated Spring Boot versions can expose your projects to security risks, leave you without access to the latest features and performance improvements, and can be costing you more money. Have you ever been working, on an outdated JVM perhaps, or an older Spring Boot version, and secretly wished you were using the latest release? I get it, I've been there too, and I'm here to help.

I want you to check out the Spring Health Assessment Report. This tool is very similar to something you probably have running already, it tells you about known vulnerabilities. However, this tool is also unique in a few very special ways. First of all, it's free for you to use. It also has the support timeline information built in. It provides a measure of how hard it will be to upgrade. Finally, it only reports on the Spring and Micrometer dependencies that you are using. It's very focused and actionable.

I like to call OpenRewrite my favorite cheat code. When I say that I demonstrate OpenRewrite twenty times per week, I'm not exaggerating. It's a powerful tool, and I'm still surprised by how many developers still don't know about it. This repository includes one of those demos, that I deliver multiple times every week.

Software is soft for a reason. It's meant to be changed. It's meant to be upgraded. It's meant to be improved. Java comes out with a new JVM, every 6-months. The Spring team releases a new Spring Boot version every 6-months. It's time to start upgrading more frequently. In 2023, there were only 4-weeks, of the entire year, that the Spring team didn't release something new. You can see for yourself over at calendar-dot-spring-dot-io. It's time to start upgrading more frequently.

I believe that the way software is going to be measured, going forward, is by how easy it is to maintain. I'm convinced that continuous upgrading, and continuous patching, is going to be a key differentiator for software projects. I want you to get started, today.

By upgrading your Spring Boot projects, you can benefit from improved security, performance, and access to the latest features. You'll also be able to take advantage of the ongoing support and updates provided by the Spring team and the Java team!

So why wait? Watch this video I made last week. Check out the Spring Health Assessment Report. You will see a few reasons why you should upgrade. You will also see how easy it can be. Spring Boot 3.2.3 comes out next Thursday, how long will it take you to upgrade?

Five Months in the making, multi-architecture builder

DaShaun — Mon, 18 Sep 2023 00:09:00 +0000

Long-overdue version of multi-architecture buildpack with Spring Boot 3 AOT processing support for M1, Raspberry Pi, ARM64

If you have been following along, you are probably asking "What took so long?" and I totally understand.
I had no idea what was wrong before today.
My scripts had been working for over a year, then just stopped.
I had removed a bunch of the debug info from the logs, which didn't help the situation at all.

Upstream progress

The Paketo team continues to put a high priority on ARM64 and multi-architecture tools/buildpacks.
I had created several ARM64 workarounds over the years.
The Paketo team continued improving their tools to support ARM64 as well.
I was not doing a good job of pulling the tooling changes from upstream.
So my workarounds were breaking the build.

Several failed attempts

I had made several solid attempts at resolving the issues.
I just kept getting distracted with other priorities.
I have had this process working on multiple environments.
Every version of my pipeline seemed to be broken in a slightly different way.
They were, because of my workarounds.
I had different workarounds for different environments.

Motivation

This year, I've been traveling more than ever.
In fact, I'm on my way to Oracle Cloud World 2023, right now.
The laptop that I was using for work, wasn't keeping up with what I was needing to deliver, to the community.
My conference sessions were having issues, my customer sessions were also having issues.
Watching for over 4-minutes, for a native compile, isn't great for anyone.
So I requested a new M1 laptop.
When I got home on Friday, my new laptop had arrived.
Since I'm going to be working on an M1 from now on, I needed to have all the fast builds.
I needed to make sure all of my demos work on the new hardware.
I also needed to be ready to use Java 21 when it comes out in 2 days.
In addition to my new laptop from work, my Ampere Dev Kit server also arrived.
The server had been stuck in US Customs for a couple of months, after arriving from China.
It was my first time working with US Customs.

M1
Ampere Dev Kit
Java 21

The work

On my new M1, I simply started adding in debug info to the scripts.
It felt good to get back into the process and remind myself how it all worked.
When things work, you don't need to keep the details in your mental cache.
The upstream builder added a few buildpacks.
Packaging the newer buildpacks is where the problems were.
Moments ago, I was getting ready to board when my tests passed.
The KC Chiefs were playing Jacksonville at the same time.
When I shouted with excitement, the people around me assumed that I was watching the game.
I love my job.
I love what I do.
I could hear the Chiefs game, but getting this build to work was even more exciting that watching the Chiefs win the Super Bowl, twice.

A huge surprise

I don't remember what the number was, from the last time I looked at the stats on Docker Hub.
When I went to look today, I was hoping for it to be over 2000.
Maybe 3000? Is 5000 possible?
My goosebumps hit when I saw that it was over 8500!
I am so excited that people are using it.

Next steps

I am going to try to move away from my scripts, towards what the Paketo team is doing.
I want to get my version moved over to the paketo-community repository.
Hopefully, from there, it will be even closer to being merged upstream.

Stay tuned!

Feedback welcome

Please let me know how it is working for you, all of my socials/contact info can be found here.

Teamwork makes the dream work for this multi-architecture builder.

DaShaun — Tue, 13 Dec 2022 04:28:48 +0000

Teamwork makes the dream work for this multi-architecture builder

There has never been a better time to start delivering Spring Boot applications to ARM64 architectures. I've been working on ARM64 buildpacks for over a year now and I want you to see how far things have come. These last few days have been leveled-up with help from Daniel Mikusa and Salman Malik, and the results are amazing.

So close

I'm excited because the builder for ARM64 is so close to the AMD64 builder supported by Paketo. To see just how close things are, we can do a simple diff of the builders, from different architectures.

Optionally, clear cached images first
docker system prune -a --volumes -f

Inspect with ARM64

On an ARM64 device:

pack builder inspect dashaun/builder:tiny > ~/dashaun.builder.tiny.arm64

The file should look like this:

Inspecting builder: dashaun/builder:tiny

REMOTE:

Description: Tiny base image (bionic build image, distroless-like run image) with buildpacks for Java, Java Native Image and Go

Created By:
Name: Pack CLI
Version: 0.28.0+git-b10e41f.build-3729

Trusted: No

Stack:
ID: io.paketo.stacks.tiny

Lifecycle:
Version: 0.15.2
Buildpack APIs:
Deprecated: (none)
Supported: 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9
Platform APIs:
Deprecated: (none)
Supported: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10

Run Images:
index.docker.io/paketobuildpacks/run:tiny-cnb
gcr.io/paketo-buildpacks/run:tiny-cnb

Buildpacks:
ID                                                  NAME                                                   VERSION        HOMEPAGE
paketo-buildpacks/apache-tomcat                     Paketo Buildpack for Apache Tomcat                     7.9.1          https://github.com/paketo-buildpacks/apache-tomcat
paketo-buildpacks/apache-tomee                      Paketo Buildpack for Apache Tomee                      1.4.0          https://github.com/paketo-buildpacks/apache-tomee
paketo-buildpacks/azure-application-insights        Paketo Buildpack for Azure Application Insights        5.9.3          https://github.com/paketo-buildpacks/azure-application-insights
paketo-buildpacks/bellsoft-liberica                 Paketo Buildpack for BellSoft Liberica                 9.10.1         https://github.com/paketo-buildpacks/bellsoft-liberica
paketo-buildpacks/ca-certificates                   Paketo Buildpack for CA Certificates                   3.5.1          https://github.com/paketo-buildpacks/ca-certificates
paketo-buildpacks/clojure-tools                     Paketo Buildpack for Clojure Tools                     2.6.1          https://github.com/paketo-buildpacks/clojure-tools
paketo-buildpacks/datadog                           Paketo Buildpack for Datadog                           3.1.0          https://github.com/paketo-buildpacks/datadog
paketo-buildpacks/dist-zip                          Paketo Buildpack for DistZip                           5.4.0          https://github.com/paketo-buildpacks/dist-zip
paketo-buildpacks/encrypt-at-rest                   Paketo Buildpack for Encrypt-at-Rest                   4.3.2          https://github.com/paketo-buildpacks/encrypt-at-rest
paketo-buildpacks/environment-variables             Paketo Buildpack for Environment Variables             4.4.0          https://github.com/paketo-buildpacks/environment-variables
paketo-buildpacks/executable-jar                    Paketo Buildpack for Executable JAR                    6.5.0          https://github.com/paketo-buildpacks/executable-jar
paketo-buildpacks/git                               Paketo Buildpack for Git                               1.0.0          https://github.com/paketo-buildpacks/git
paketo-buildpacks/go                                Paketo Buildpack for Go                                4.0.0          https://github.com/paketo-buildpacks/go
paketo-buildpacks/go-build                          Paketo Buildpack for Go Build                          2.0.7          https://github.com/paketo-buildpacks/go-build
paketo-buildpacks/go-dist                           Paketo Buildpack for Go Distribution                   2.2.2          https://github.com/paketo-buildpacks/go-dist
paketo-buildpacks/go-mod-vendor                     Paketo Buildpack for Go Mod Vendor                     1.0.6          https://github.com/paketo-buildpacks/go-mod-vendor
paketo-buildpacks/google-stackdriver                Paketo Buildpack for Google Stackdriver                7.0.0          https://github.com/paketo-buildpacks/google-stackdriver
paketo-buildpacks/gradle                            Paketo Buildpack for Gradle                            6.10.0         https://github.com/paketo-buildpacks/gradle
paketo-buildpacks/image-labels                      Paketo Buildpack for Image Labels                      4.3.0          https://github.com/paketo-buildpacks/image-labels
paketo-buildpacks/jattach                           Paketo Buildpack for JAttach                           1.2.0          https://github.com/paketo-buildpacks/jattach
paketo-buildpacks/java                              Paketo Buildpack for Java                              8.1.0          https://paketo.io/docs/howto/java
paketo-buildpacks/java-memory-assistant             Paketo Buildpack for Java Memory Assistant             1.2.0          https://github.com/paketo-buildpacks/java-memory-assistant
paketo-buildpacks/java-native-image                 Paketo Buildpack for Java Native Image                 7.42.0         https://paketo.io/docs/howto/java/#build-an-app-as-a-graalvm-native-image-application
paketo-buildpacks/leiningen                         Paketo Buildpack for Leiningen                         4.4.0          https://github.com/paketo-buildpacks/leiningen
paketo-buildpacks/liberty                           Paketo Buildpack for Liberty                           3.1.0          https://github.com/paketo-buildpacks/liberty
paketo-buildpacks/maven                             Paketo Buildpack for Maven                             6.11.0         https://github.com/paketo-buildpacks/maven
paketo-buildpacks/native-image                      Paketo Buildpack for Native Image                      5.6.0          https://github.com/paketo-buildpacks/native-image
paketo-buildpacks/procfile                          Paketo Buildpack for Procfile                          5.5.0          https://github.com/paketo-buildpacks/procfile
paketo-buildpacks/sbt                               Paketo Buildpack for SBT                               6.9.0          https://github.com/paketo-buildpacks/sbt
paketo-buildpacks/spring-boot                       Paketo Buildpack for Spring Boot                       5.20.0         https://github.com/paketo-buildpacks/spring-boot
paketo-buildpacks/syft                              Paketo Buildpack for Syft                              1.23.0         https://github.com/paketo-buildpacks/syft
paketo-buildpacks/upx                               Paketo Buildpack for UPX                               3.3.0          https://github.com/paketo-buildpacks/upx
paketo-buildpacks/watchexec                         Paketo Buildpack for Watchexec                         2.7.0          https://github.com/paketo-buildpacks/watchexec

Detection Order:
├ Group #1:
│  └ paketo-buildpacks/java-native-image@7.42.0
│     └ Group #1:
│        ├ paketo-buildpacks/ca-certificates@3.5.1          (optional)
│        ├ paketo-buildpacks/upx@3.3.0                      (optional)
│        ├ paketo-buildpacks/bellsoft-liberica@9.10.1
│        ├ paketo-buildpacks/syft@1.23.0                    (optional)
│        ├ paketo-buildpacks/leiningen@4.4.0                (optional)
│        ├ paketo-buildpacks/gradle@6.10.0                  (optional)
│        ├ paketo-buildpacks/maven@6.11.0                   (optional)
│        ├ paketo-buildpacks/sbt@6.9.0                      (optional)
│        ├ paketo-buildpacks/executable-jar@6.5.0           (optional)
│        ├ paketo-buildpacks/spring-boot@5.20.0             (optional)
│        ├ paketo-buildpacks/native-image@5.6.0
│        ├ paketo-buildpacks/procfile@5.5.0                 (optional)
│        ├ paketo-buildpacks/environment-variables@4.4.0    (optional)
│        └ paketo-buildpacks/image-labels@4.3.0             (optional)
├ Group #2:
│  └ paketo-buildpacks/java@8.1.0
│     └ Group #1:
│        ├ paketo-buildpacks/ca-certificates@3.5.1               (optional)
│        ├ paketo-buildpacks/bellsoft-liberica@9.10.1
│        ├ paketo-buildpacks/syft@1.23.0                         (optional)
│        ├ paketo-buildpacks/leiningen@4.4.0                     (optional)
│        ├ paketo-buildpacks/clojure-tools@2.6.1                 (optional)
│        ├ paketo-buildpacks/gradle@6.10.0                       (optional)
│        ├ paketo-buildpacks/maven@6.11.0                        (optional)
│        ├ paketo-buildpacks/sbt@6.9.0                           (optional)
│        ├ paketo-buildpacks/watchexec@2.7.0                     (optional)
│        ├ paketo-buildpacks/executable-jar@6.5.0                (optional)
│        ├ paketo-buildpacks/apache-tomcat@7.9.1                 (optional)
│        ├ paketo-buildpacks/apache-tomee@1.4.0                  (optional)
│        ├ paketo-buildpacks/liberty@3.1.0                       (optional)
│        ├ paketo-buildpacks/dist-zip@5.4.0                      (optional)
│        ├ paketo-buildpacks/spring-boot@5.20.0                  (optional)
│        ├ paketo-buildpacks/procfile@5.5.0                      (optional)
│        ├ paketo-buildpacks/jattach@1.2.0                       (optional)
│        ├ paketo-buildpacks/azure-application-insights@5.9.3    (optional)
│        ├ paketo-buildpacks/google-stackdriver@7.0.0            (optional)
│        ├ paketo-buildpacks/datadog@3.1.0                       (optional)
│        ├ paketo-buildpacks/java-memory-assistant@1.2.0         (optional)
│        ├ paketo-buildpacks/encrypt-at-rest@4.3.2               (optional)
│        ├ paketo-buildpacks/environment-variables@4.4.0         (optional)
│        └ paketo-buildpacks/image-labels@4.3.0                  (optional)
├ Group #3:
│  ├ paketo-buildpacks/go@4.0.0
│  │  └ Group #1:
│  │     ├ paketo-buildpacks/ca-certificates@3.5.1          (optional)
│  │     ├ paketo-buildpacks/watchexec@2.7.0                (optional)
│  │     ├ paketo-buildpacks/go-dist@2.2.2
│  │     ├ paketo-buildpacks/git@1.0.0                      (optional)
│  │     ├ paketo-buildpacks/go-mod-vendor@1.0.6
│  │     ├ paketo-buildpacks/go-build@2.0.7
│  │     ├ paketo-buildpacks/procfile@5.5.0                 (optional)
│  │     ├ paketo-buildpacks/environment-variables@4.4.0    (optional)
│  │     └ paketo-buildpacks/image-labels@4.3.0             (optional)
│  └ paketo-buildpacks/go@4.0.0
│     └ Group #2:
│        ├ paketo-buildpacks/ca-certificates@3.5.1          (optional)
│        ├ paketo-buildpacks/watchexec@2.7.0                (optional)
│        ├ paketo-buildpacks/go-dist@2.2.2
│        ├ paketo-buildpacks/git@1.0.0                      (optional)
│        ├ paketo-buildpacks/go-build@2.0.7
│        ├ paketo-buildpacks/procfile@5.5.0                 (optional)
│        ├ paketo-buildpacks/environment-variables@4.4.0    (optional)
│        └ paketo-buildpacks/image-labels@4.3.0             (optional)
└ Group #4:
└ paketo-buildpacks/procfile@5.5.0

LOCAL:
(not present)

Inspect with AMD64

On an AMD64 device:

pack builder inspect dashaun/builder:tiny > ~/dashaun.builder.tiny.amd64

The file will look very similar:

Inspecting builder: dashaun/builder:tiny

REMOTE:

Description: Tiny base image (bionic build image, distroless-like run image) with buildpacks for Java, Java Native Image and Go

Created By:
  Name: Pack CLI
  Version: 0.28.0+git-b10e41f.build-3729

Trusted: No

Stack:
  ID: io.paketo.stacks.tiny

Lifecycle:
  Version: 0.15.2
  Buildpack APIs:
    Deprecated: (none)
    Supported: 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9
  Platform APIs:
    Deprecated: (none)
    Supported: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10

Run Images:
  index.docker.io/paketobuildpacks/run:tiny-cnb
  gcr.io/paketo-buildpacks/run:tiny-cnb

Buildpacks:
  ID                                                  NAME                                                   VERSION        HOMEPAGE
  paketo-buildpacks/apache-tomcat                     Paketo Buildpack for Apache Tomcat                     7.9.1          https://github.com/paketo-buildpacks/apache-tomcat
  paketo-buildpacks/apache-tomee                      Paketo Buildpack for Apache Tomee                      1.4.0          https://github.com/paketo-buildpacks/apache-tomee
  paketo-buildpacks/azure-application-insights        Paketo Buildpack for Azure Application Insights        5.9.3          https://github.com/paketo-buildpacks/azure-application-insights
  paketo-buildpacks/bellsoft-liberica                 Paketo Buildpack for BellSoft Liberica                 9.10.1         https://github.com/paketo-buildpacks/bellsoft-liberica
  paketo-buildpacks/ca-certificates                   Paketo Buildpack for CA Certificates                   3.5.1          https://github.com/paketo-buildpacks/ca-certificates
  paketo-buildpacks/clojure-tools                     Paketo Buildpack for Clojure Tools                     2.6.1          https://github.com/paketo-buildpacks/clojure-tools
  paketo-buildpacks/datadog                           Paketo Buildpack for Datadog                           3.1.0          https://github.com/paketo-buildpacks/datadog
  paketo-buildpacks/dist-zip                          Paketo Buildpack for DistZip                           5.4.0          https://github.com/paketo-buildpacks/dist-zip
  paketo-buildpacks/encrypt-at-rest                   Paketo Buildpack for Encrypt-at-Rest                   4.3.2          https://github.com/paketo-buildpacks/encrypt-at-rest
  paketo-buildpacks/environment-variables             Paketo Buildpack for Environment Variables             4.4.0          https://github.com/paketo-buildpacks/environment-variables
  paketo-buildpacks/executable-jar                    Paketo Buildpack for Executable JAR                    6.5.0          https://github.com/paketo-buildpacks/executable-jar
  paketo-buildpacks/git                               Paketo Buildpack for Git                               1.0.0          https://github.com/paketo-buildpacks/git
  paketo-buildpacks/go                                Paketo Buildpack for Go                                4.0.0          https://github.com/paketo-buildpacks/go
  paketo-buildpacks/go-build                          Paketo Buildpack for Go Build                          2.0.7          https://github.com/paketo-buildpacks/go-build
  paketo-buildpacks/go-dist                           Paketo Buildpack for Go Distribution                   2.2.2          https://github.com/paketo-buildpacks/go-dist
  paketo-buildpacks/go-mod-vendor                     Paketo Buildpack for Go Mod Vendor                     1.0.6          https://github.com/paketo-buildpacks/go-mod-vendor
  paketo-buildpacks/google-stackdriver                Paketo Buildpack for Google Stackdriver                7.0.0          https://github.com/paketo-buildpacks/google-stackdriver
  paketo-buildpacks/gradle                            Paketo Buildpack for Gradle                            6.10.0         https://github.com/paketo-buildpacks/gradle
  paketo-buildpacks/image-labels                      Paketo Buildpack for Image Labels                      4.3.0          https://github.com/paketo-buildpacks/image-labels
  paketo-buildpacks/jattach                           Paketo Buildpack for JAttach                           1.2.0          https://github.com/paketo-buildpacks/jattach
  paketo-buildpacks/java                              Paketo Buildpack for Java                              8.1.0          https://paketo.io/docs/howto/java
  paketo-buildpacks/java-memory-assistant             Paketo Buildpack for Java Memory Assistant             1.2.0          https://github.com/paketo-buildpacks/java-memory-assistant
  paketo-buildpacks/java-native-image                 Paketo Buildpack for Java Native Image                 7.42.0         https://paketo.io/docs/howto/java/#build-an-app-as-a-graalvm-native-image-application
  paketo-buildpacks/leiningen                         Paketo Buildpack for Leiningen                         4.4.0          https://github.com/paketo-buildpacks/leiningen
  paketo-buildpacks/liberty                           Paketo Buildpack for Liberty                           3.1.0          https://github.com/paketo-buildpacks/liberty
  paketo-buildpacks/maven                             Paketo Buildpack for Maven                             6.11.0         https://github.com/paketo-buildpacks/maven
  paketo-buildpacks/native-image                      Paketo Buildpack for Native Image                      5.6.0          https://github.com/paketo-buildpacks/native-image
  paketo-buildpacks/procfile                          Paketo Buildpack for Procfile                          5.5.0          https://github.com/paketo-buildpacks/procfile
  paketo-buildpacks/sbt                               Paketo Buildpack for SBT                               6.9.0          https://github.com/paketo-buildpacks/sbt
  paketo-buildpacks/spring-boot                       Paketo Buildpack for Spring Boot                       5.20.0         https://github.com/paketo-buildpacks/spring-boot
  paketo-buildpacks/syft                              Paketo Buildpack for Syft                              1.23.0         https://github.com/paketo-buildpacks/syft
  paketo-buildpacks/upx                               Paketo Buildpack for UPX                               3.3.0          https://github.com/paketo-buildpacks/upx
  paketo-buildpacks/watchexec                         Paketo Buildpack for Watchexec                         2.7.0          https://github.com/paketo-buildpacks/watchexec

Detection Order:
 ├ Group #1:
 │  └ paketo-buildpacks/java-native-image@7.42.0
 │     └ Group #1:
 │        ├ paketo-buildpacks/ca-certificates@3.5.1          (optional)
 │        ├ paketo-buildpacks/upx@3.3.0                      (optional)
 │        ├ paketo-buildpacks/bellsoft-liberica@9.10.1
 │        ├ paketo-buildpacks/syft@1.23.0                    (optional)
 │        ├ paketo-buildpacks/leiningen@4.4.0                (optional)
 │        ├ paketo-buildpacks/gradle@6.10.0                  (optional)
 │        ├ paketo-buildpacks/maven@6.11.0                   (optional)
 │        ├ paketo-buildpacks/sbt@6.9.0                      (optional)
 │        ├ paketo-buildpacks/executable-jar@6.5.0           (optional)
 │        ├ paketo-buildpacks/spring-boot@5.20.0             (optional)
 │        ├ paketo-buildpacks/native-image@5.6.0
 │        ├ paketo-buildpacks/procfile@5.5.0                 (optional)
 │        ├ paketo-buildpacks/environment-variables@4.4.0    (optional)
 │        └ paketo-buildpacks/image-labels@4.3.0             (optional)
 ├ Group #2:
 │  └ paketo-buildpacks/java@8.1.0
 │     └ Group #1:
 │        ├ paketo-buildpacks/ca-certificates@3.5.1               (optional)
 │        ├ paketo-buildpacks/bellsoft-liberica@9.10.1
 │        ├ paketo-buildpacks/syft@1.23.0                         (optional)
 │        ├ paketo-buildpacks/leiningen@4.4.0                     (optional)
 │        ├ paketo-buildpacks/clojure-tools@2.6.1                 (optional)
 │        ├ paketo-buildpacks/gradle@6.10.0                       (optional)
 │        ├ paketo-buildpacks/maven@6.11.0                        (optional)
 │        ├ paketo-buildpacks/sbt@6.9.0                           (optional)
 │        ├ paketo-buildpacks/watchexec@2.7.0                     (optional)
 │        ├ paketo-buildpacks/executable-jar@6.5.0                (optional)
 │        ├ paketo-buildpacks/apache-tomcat@7.9.1                 (optional)
 │        ├ paketo-buildpacks/apache-tomee@1.4.0                  (optional)
 │        ├ paketo-buildpacks/liberty@3.1.0                       (optional)
 │        ├ paketo-buildpacks/dist-zip@5.4.0                      (optional)
 │        ├ paketo-buildpacks/spring-boot@5.20.0                  (optional)
 │        ├ paketo-buildpacks/procfile@5.5.0                      (optional)
 │        ├ paketo-buildpacks/jattach@1.2.0                       (optional)
 │        ├ paketo-buildpacks/azure-application-insights@5.9.3    (optional)
 │        ├ paketo-buildpacks/google-stackdriver@7.0.0            (optional)
 │        ├ paketo-buildpacks/datadog@3.1.0                       (optional)
 │        ├ paketo-buildpacks/java-memory-assistant@1.2.0         (optional)
 │        ├ paketo-buildpacks/encrypt-at-rest@4.3.2               (optional)
 │        ├ paketo-buildpacks/environment-variables@4.4.0         (optional)
 │        └ paketo-buildpacks/image-labels@4.3.0                  (optional)
 ├ Group #3:
 │  ├ paketo-buildpacks/go@4.0.0
 │  │  └ Group #1:
 │  │     ├ paketo-buildpacks/ca-certificates@3.5.1          (optional)
 │  │     ├ paketo-buildpacks/watchexec@2.7.0                (optional)
 │  │     ├ paketo-buildpacks/go-dist@2.2.2
 │  │     ├ paketo-buildpacks/git@1.0.0                      (optional)
 │  │     ├ paketo-buildpacks/go-mod-vendor@1.0.6
 │  │     ├ paketo-buildpacks/go-build@2.0.7
 │  │     ├ paketo-buildpacks/procfile@5.5.0                 (optional)
 │  │     ├ paketo-buildpacks/environment-variables@4.4.0    (optional)
 │  │     └ paketo-buildpacks/image-labels@4.3.0             (optional)
 │  └ paketo-buildpacks/go@4.0.0
 │     └ Group #2:
 │        ├ paketo-buildpacks/ca-certificates@3.5.1          (optional)
 │        ├ paketo-buildpacks/watchexec@2.7.0                (optional)
 │        ├ paketo-buildpacks/go-dist@2.2.2
 │        ├ paketo-buildpacks/git@1.0.0                      (optional)
 │        ├ paketo-buildpacks/go-build@2.0.7
 │        ├ paketo-buildpacks/procfile@5.5.0                 (optional)
 │        ├ paketo-buildpacks/environment-variables@4.4.0    (optional)
 │        └ paketo-buildpacks/image-labels@4.3.0             (optional)
 └ Group #4:
    └ paketo-buildpacks/procfile@5.5.0

LOCAL:
(not present)

Now, take a look at the diff between those two files:

diff dashaun.builder.tiny.arm64 dashaun.builder.tiny.amd64

As I'm writing this, the diff looks like this:


text
< Inspecting builder: 'dashaun/builder:tiny'

Spring Cloud Gateway 4.0.0-RC2 native example with Testcontainers

DaShaun — Fri, 09 Dec 2022 01:24:19 +0000

Spring Cloud Gateway 4.0.0-RC2 native example with Testcontainers

This example repository is on GitHub

There are 3 goals I have for this example:

Deliver Spring Cloud Gateway as a graalvm-native-image with Spring Boot 3
Get feedback on the multi-architecture buildpack that includes ARM64 support
Demonstrate a pattern for building and testing buildpack images using Testcontainers

Spring Cloud Gateway

From the Spring.io website:

Spring Cloud Gateway aims to provide a simple,
yet effective way to route to APIs and provide
cross cutting concerns to them such as:
security, monitoring/metrics, and resiliency.

It is very popular, and even more valuable than it is popular!

Spring Framework 6 and Spring Boot 3.0.0 have recently gone GA. My favorite feature of these new releases is hands down the AOT processing. The AOT processing, provided by GraalVM, creates statically linked binary images. These images are optimized, ahead of time, for the operating system and architecture. For many modern workloads they can provide smaller image sizes, smaller memory footprint, and a much faster startup time.

In a recent experiment, I was able to expose Spring Cloud Gateway to the public, and have it route to other Spring Boot 3 native image workloads.

In that experiment Spring Cloud Gateway provided:

Single service for SSL and ingress integration
YAML configured routing
Circuit Breaker capabilities with Resilience4j
Request Rate Limiting with Redis

In the experiment, I left the Spring Cloud Gateway running, by setting the min-scale value to 1.

metadata:
  name: spring-cloud-gateway
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/initial-scale: "1"
        autoscaling.knative.dev/min-scale: "1"
        autoscaling.knative.dev/max-scale: "2"
    spec:
      containers:
        - image: dashaun/dev.dashaun.service.gateway:latest

The other Spring Boot applications, being routed to by the gateway, were allowed to scale-to-zero when they weren't used.

The experiment was on a cluster of Raspberry Pi devices which are ARM64 cpus.

The Spring Cloud Gateway, native image, typically starts up between 0.600s and 0.650s, on a Raspberry Pi.

Today, the buildpack delivered by Spring Initializr at start.spring.io, is unable to create native images on ARM64.

Multi-architecture buildpack

Earlier this year, I started working on a buildpack to use with the experimental project, Spring Native, and ARM64, for my Raspberry Pi devices. Later the M1/M2 Apple Silicon community, also ARM64, began showing interest in using this buildpack. I have delivered a few versions to date. I've also created some automation to improve my process for creating these buildpacks.

Recently, I created a multi-architecture buildpack that can be used with Spring Boot 3, to create native images on both Intel/AMD64 and ARM64 architectures. This example repository is configured with this multi-architecture buildpack.

I'm still working to improve this builder, in an effort to get ARM64 support upstream to Paketo. I have a long way to go, but with your help, I can discover gaps and continue this effort. One of the known, and frustrating gaps today, is that UPX compression does not work on ARM64, it does work with AMD64. I really want to get this figured out, and it is a high priority for me.

Building and testing native images

One of the most common concerns I have heard from the community this year has been around validating that the native image artifacts are delivering the same results as the JIT/JVM based artifacts. This is a very valid concern. This is also why I feel, that organizations with mature testing capabilities today, will be able to move forward with native images faster.

This repository provides a BuildImageTest that uses the buildpack to create a native image. It then tests the native image, using Testcontainers and JUnit. Building the native image with AOT processing, as part of a test, takes minutes not seconds, and should not be part of normal "inner loop" development. So the BuildImageTest is in a separate sourceSet and can be executed independently. This is a very powerful pattern, that I'm just getting started with. I would love to hear your thoughts on this pattern or other alternatives to it.

To build and validate the native image:

./gradlew integrationTest

You can also execute the BuildImageTest directly in your IDE.

Thanks

I am having so much fun with all of these new capabilities and challenges. I want to thank the Spring team, for all of their amazing work bring Spring Framework 6 and Spring Boot 3 to GA. I also want to thank Daniel Mikusa and the Paketo community for being amazing to work with. I want to thank Sergei Egorov for sharing the testing pattern and supporting my Testcontainers journey. Finally, I would like to thank Dan Vega, my Spring Office Hours cohost, for being an amazing teammate, and having the JUICE.

Keep Learning

Cloud Native Buildpack for ARM64 and AMD64

DaShaun — Tue, 06 Dec 2022 22:31:40 +0000

Version 7.41.0

This builder works with Intel/AMD architectures and ARM64 architectures like Apple M1 and Raspberry Pi.

With this release I was able to use a little more automation on my side, to get my unsupported builder even closer to the upstream at Paketo.

Roadmap

I'm trying to make each of the buildpacks as similar as possible to each other and upstream.
I'm also working on delivering newer versions of the stack, which is currently Ubuntu Focal.

Feedback welcome

Please let me know how it is working for you, all of my socials/contact info can be found here.

K3s Knative Ubuntu Raspberry Pi

DaShaun — Tue, 06 Dec 2022 07:58:45 +0000

K3s Knative Ubuntu Raspberry Pi

Knative is a super exciting solution for serverless and event driven applications.
Personally, I have been using it as a part of my inner loop development.
I can deploy dozens of workloads.
All scaled down to zero when they aren't being used.
All responding and starting up quickly when they are needed.

I ran into a couple of problems with Envoy on Raspberry Pi OS.
After investigating, it is a known issue in the Raspberry Pi OS kernel.
In order to keep going forward with my project I had to choose between fixing the kernel or trying Ubuntu.

This is an overview of how to get Knative Serving working on a Raspberry Pi device with K3s and Ubuntu.

Install Ubuntu Server

Use RPI Imager.
Select Ubuntu Server 22.10 64-bit from the list of other distributions.
Boot the new image.

I was happy to see that SSH and the default user were configured as expected by using the advanced settings options.

Upgrade the stuff

# Grab the latest repository info
sudo apt update 
# Install one prerequisite package that isn't installed by default
sudo apt install linux-modules-extra-raspi -y
# Upgrade everything that can be upgraded
sudo apt dist-upgrade -y

Fix cgroup

# Add this to the beginning of /boot/firmware/cmdline.txt
# cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory
sudo nano -w /boot/firmware/cmdline.txt

Reboot after making this change.

sudo shutdown -r now

Install k3s via k3sup

From my laptop, not one of the Raspberry Pi nodes, run k3sup, it's super easy.
If you haven't figured it out by now, I'm a big fan of k3sup.

export CONTROL_NODE_IP=10.0.0.10
# Disable Traefik because we will use kourier for knative
k3sup install --ip $CONTROL_NODE_IP --user pi --k3s-extra-args '--disable traefik' --merge --local-path ~/.kube/config --context cluster00
# Knative-Serving with Kourier works on a single Raspberry Pi 4 with 8GB
# Optionally add other nodes
k3sup join --ip 10.0.0.11 --server-ip $CONTROL_NODE_IP --user pi
k3sup join --ip 10.0.0.12 --server-ip $CONTROL_NODE_IP --user pi

Deep breath

This is where I struggled with how to deliver this example.
The Knative install documentation is awesome.
I've been through it dozens of times!

I tried to simplify this for you.
I want to give you the 'easy button' experience.
I created a repository with all the YAML you need to deploy Knative Serving to this K3s cluster.

Knative Serving with Kourier

git clone https://github.com/dashaun/knative-serving-raspberry-pi
cd knative-serving-raspberry-pi/operator-serving-kourier
# Use the `default` namespace in the Kubernetes cluster
kubectl config set-context --current --namespace=default
# Deploy the Knative operator
kubectl apply -f operator.yaml
# Check the deployment status
kubectl get deployment knative-operator

Continue when Ready status is 1/1

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
knative-operator   1/1     1            1           19h

# Install Knative Serving custom resource and Kourier
kubectl apply -f knative-serving.yaml
# Check the custom resource status
kubectl get KnativeServing knative-serving -n knative-serving

Continue when READY is True

NAME              VERSION   READY   REASON
knative-serving   1.8.0     True

# Check the deployment status
kubectl get deployment -n knative-serving

Continue when READY are all 1/1

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
activator                1/1     1            1           23m
autoscaler               1/1     1            1           23m
controller               1/1     1            1           23m
domain-mapping           1/1     1            1           23m
domainmapping-webhook    1/1     1            1           23m
autoscaler-hpa           1/1     1            1           23m
3scale-kourier-gateway   1/1     1            1           23m
webhook                  1/1     1            1           23m
net-kourier-controller   1/1     1            1           23m

SSLIP.IO and a Spring Boot 3 `native` application

# Install default domain
kubectl apply -f serving-default-domain.yaml
# Deploy a Spring Boot 3 `native` application
kubectl apply -f spring-boot-native-pi-service.yaml
# Get the address
kubectl get ksvc spring-boot-native-pi --output=custom-columns=NAME:.metadata.name,URL:.status.url

NAME                    URL
spring-boot-native-pi   http://spring-boot-native-pi.default.10.0.0.10.sslip.io

# Curl the address provided by knative with `/actuator/health` at the end
curl http://spring-boot-native-pi.default.default.10.0.0.10.sslip.io/actuator/health

Expected output:
{"status":"UP"}

Summary

With the recent release of Spring Boot 3.0.0, my Raspberry Pi collection has become significantly more interesting.
Knative Serving allows me to deploy dozens of Spring Boot / Spring Cloud workloads to a tiny, low power device, with very exciting capabilities.

Keep Learning

Spring Boot 3 Buildpacks with Testcontainers Cloud

DaShaun — Tue, 22 Nov 2022 05:55:59 +0000

Background

I have a modest laptop. It checks the boxes, for just about everything I need to do for work. Just about. AOT processing, with GraalVM, is not a great experience on this machine.

The origin story

Back in June 2022, I was presenting at SpringOne Tour NYC. As part of the demo, I built a native image using Spring Boot 2.7 with the spring-native experimental dependency. The session went well, except for the building the native image part of it. During my 50-minute session, my laptop was busy building the native image for over 8-minutes, using the buildpack. It was a humbling experience. After the session, I hung out with Sergei Egorov, and we worked on something very special. With help from one of his previous blog posts, we created a proof of concept. We used Testcontainers Cloud to build the native OCI image, in the cloud, in a little over 3-minutes. Pairing with Sergei is amazing, if you get the chance, I highly recommend it.

It sat on the back-burner and fire is hot

I had this code sitting in my repository, waiting to be used. When it was time for SpringOne Tour Tel Aviv, Nov 2022, I was ready to show it off. Unfortunately for me, my session was shortened, so I pulled it out of the presentation. I shouldn’t have pulled it out, I made the exact same mistake that I made in NYC. When I built the native image using buildpacks, it took way too long on my laptop.

Momentum

My adventures with buildpacks have been top of mind for a couple of weeks now. Oleg Šelajev and Cora Iberklied also presented about testcontainers in Tel Aviv. The stage was set for me to take this use case further.

The Goal

Build Spring Boot 3, native OCI images, with buildpacks, during demos, faster, with Testcontainers Cloud

Prerequisites

You need to have an account at https://testcontainers.cloud.

Login to your account

I’m logging in with v1.3.11 of the cloud desktop app for Mac, this is still in private beta at the time of this writing.

docker context list

You should see at least one context named ’tcc'

docker context use tcc

Create an application example

Create a Spring Boot 3 application with web, actuator, and testcontainers for a simple test.

curl https://start.spring.io/starter.tgz -d dependencies=web,actuator,testcontainers -d javaVersion=17 -d bootVersion=3.0.0-RC2 -d type=maven-project | tar -xzf -

Spring Boot 3 goes GA later this week, but I can’t wait that long

In the pom.xml add this dependency:

<dependency>
    <groupId>org.apache.maven.shared</groupId>
    <artifactId>maven-invoker</artifactId>
    <version>3.2.0</version>
    <scope>test</scope>
</dependency>

Add this property:

<testcontainers.version>1.17.6</testcontainers.version>

Add this dependency management section:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.testcontainers</groupId>
            <artifactId>testcontainers-bom</artifactId>
            <version>${testcontainers.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Those pieces will allow you to write a test, that creates an OCI image, using buildpacks, with Testcontainers Cloud.

Write the test class

Here is the test class that I’ve been reusing since June.

package com.example.demo;

import org.apache.maven.shared.invoker.DefaultInvocationRequest;
import org.apache.maven.shared.invoker.DefaultInvoker;
import org.apache.maven.shared.invoker.InvocationResult;
import org.apache.maven.shared.invoker.MavenInvocationException;
import org.junit.jupiter.api.Test;
import org.springframework.util.DigestUtils;
import org.testcontainers.DockerClientFactory;
import org.testcontainers.containers.GenericContainer;
import org.testcontainers.utility.LazyFuture;

import java.io.File;
import java.util.List;
import java.util.Properties;
import java.util.concurrent.Future;

public class TccTest {
    private static final Future<String> IMAGE_FUTURE = new LazyFuture<>() {
        @Override
        protected String resolve() {
            // Find project's root dir
            File cwd;
            for (
                    cwd = new File(".");
                    !new File(cwd, "mvnw").isFile();
                    cwd = cwd.getParentFile()
            );

            // Make it unique per folder (for caching)
            var imageName = String.format(
                    "local/app-%s:%s",
                    DigestUtils.md5DigestAsHex(cwd.getAbsolutePath().getBytes()),
                    System.currentTimeMillis()
            );

            var properties = new Properties();
            properties.put("spring-boot.build-image.imageName", imageName);
            properties.put("skipTests", "true");

            var request = new DefaultInvocationRequest()
                    .addShellEnvironment("DOCKER_HOST", DockerClientFactory.instance().getTransportConfig().getDockerHost().toString())
                    .setPomFile(new File(cwd, "pom.xml"))
                    .setGoals(List.of("spring-boot:build-image"))
                    .setMavenExecutable(new File(cwd, "mvnw"))
                    .setProfiles(List.of("native"))
                    .setProperties(properties);

            InvocationResult invocationResult = null;
            try {
                invocationResult = new DefaultInvoker().execute(request);
            } catch (MavenInvocationException e) {
                throw new RuntimeException(e);
            }

            if (invocationResult.getExitCode() != 0) {
                throw new RuntimeException(invocationResult.getExecutionException());
            }

            return imageName;
        }
    };

    static final GenericContainer<?> APP = new GenericContainer<>(IMAGE_FUTURE)
            .withExposedPorts(8080);

    @Test
    void letsGo() throws Exception {
        APP.start();
    }
}

In my example repository, I actually create test classes for a regular OCI image and a native OCI image.

Verify

./mvnw clean test

Boom! You get an OCI image, or two if you use my example repository.

docker images | grep "local"

Enjoy!

Summary

This is slick. It brings me joy. When I am presenting this topic, I no longer need to have Docker Desktop running on my laptop. Therefore, my laptop battery will last longer. My builds will be consistently faster, using Testcontainers Cloud, and my demos will be smoother.

I am completely rethinking a few of my own use cases. I will definitely create more Testcontainers Cloud content in the future.

Please let me know what you think!

First attempt at a multi-arch buildpack for Spring Boot 3

DaShaun — Sat, 12 Nov 2022 13:58:51 +0000

My previous builder generated some fabulous feedback, including an issue in GitHub. It also opened the door for some wonderful collaborations while I have been traveling to Barcelona and Tel Aviv.

On this journey of trying to get ARM64 support into the upstream Paketo buildpacks I have learned so much. The next step is to prove that we can create the pipelines that can deliver a multi-architecture image.

Skip to the Quick Start here

Docker manifest

In order to see the architecture of an image, you can use the docker manifest command.

# Inspect shows the image architecture
docker manifest inspect --verbose dashaun/java-native-builder-arm64:7.37.0

Inspecting the ARM64 builder that was created in earlier article

Create a new manifest list

The process for slapping docker images together is pretty simple. Ideally you should be using the “same” image, but we are just proving a point here.

My theory is that if I provide an arm64 architecture and an amd64 architecture to the same manifest list, that it will work as expected.

# create a new manifest with a name and tag
docker manifest create dashaun/java-native-builder-multiarch:7.37.0 \
# add ARM64 builder
--amend dashaun/java-native-builder-arm64:7.37.0 \
# add Paketo tiny builder for AMD64
--amend paketobuildpacks/builder:tiny

# push the manifest to the repository
docker manifest push dashaun/java-native-builder-multiarch:7.37.0

That’s it!

inspect the manifest list - the builder

Now you can inspect the manifest and see that it has packaged ARM64 and AMD64 architectures. This capability has been available for years. It is also surprisingly simple to accomplish as you can see.

docker manifest inspect --verbose dashaun/java-native-builder-multiarch:7.37.0


[
    {
        "Ref": "docker.io/dashaun/java-native-builder-arm64:7.37.0",
        "Descriptor": {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "digest": "sha256:80771c9c2efee25020ba60e320c41cc385a333434ad2982ed7326a0a413b9ae7",
            "size": 5150,
            "platform": {
                "architecture": "arm64",
                "os": "linux"
            }
        },
        "SchemaV2Manifest": {
            "schemaVersion": 2,
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "config": {
                "mediaType": "application/vnd.docker.container.image.v1+json",
                "size": 12587,
                "digest": "sha256:8cd1ead83689b853055ac2de0cc07c5f3c9d8d087b2ac97e838551fe8e962e00"
            },
            "layers": [
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 27195998,
                    "digest": "sha256:4e7e0215f4adc2c48ad9cb3b3781e21d474b477587f85682c2e2975ae91dce9d"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 4348,
                    "digest": "sha256:fc2e670f062f6edbb1b3be6aae88cbc0978a5273314c365bc4e99d861dfb5ff1"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 103281689,
                    "digest": "sha256:cba3892e6fcca4b47983803d53b777bc05476639fcfc1a2d4f384eac40363677"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 179,
                    "digest": "sha256:f5230b5f167cfc41fb9f96d53de0d9c5832e3b03e3a705052cf42ceada13aea9"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 197,
                    "digest": "sha256:357fefdf9bc907107a38600cf8d79c713346dc97370273d1aa79635d97a2f6f9"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 8870380,
                    "digest": "sha256:0ab7ccc1e1a42589b53d1397672009a979b296933efc276d79d3a2cdc336656c"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2498256,
                    "digest": "sha256:fa161ac7a0015773c3f6890d6f1824957a6e21cee5a9bbf8ddc60e4e6d30a3ed"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1806073,
                    "digest": "sha256:bdfdd20caee6a7044607d11d9a4f758a007ad2d61399ea5e3db22a7037ab4975"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3273385,
                    "digest": "sha256:bc251569386a8e5fd513c85d9c51e76a258f0e59d0f945e185e101930012c9db"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1509592,
                    "digest": "sha256:caeca36964d2da6c2b88abd998281e4fd5b708cfdd1440486f6acf7bc569292e"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3191207,
                    "digest": "sha256:f840d9ee444653d04a2181d1d99e4f579d01b56349cce9325c6dade9af410998"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3273637,
                    "digest": "sha256:b4f56cede28073295dc750e93678876a55b9fdafd97c940b97dc9a01ae345663"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2387292,
                    "digest": "sha256:cebaf5f7c6e3350f5973f2c77f9ba90138d5a6bb2f1eb9e86084c8cf9f6117c6"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 4208510,
                    "digest": "sha256:47be0bf349071cb594970ef2d18f383b91231645ba49f27b5b39b47d9090aedc"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1818619,
                    "digest": "sha256:5844db3d59f2bdc13aa19a6fd09789cf4a12aa87088759840a79c10eb01f93c5"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1569855,
                    "digest": "sha256:89975d6b7daf9b8cf8b1a8350461e9e009b0ffc2a482becb9e1073adc3475153"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2413551,
                    "digest": "sha256:aca3b8db4220fa7d69bf9cbd0bebc048cfa381174929828affb820c5b6b0f505"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2480839,
                    "digest": "sha256:71bd4e702bfc97f1db60e6a5ac364897b2818dc2f92f1bf9d78c2935a1ae125d"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2521983,
                    "digest": "sha256:3e1f506f69017dbcedb2a2b022ff0d6e63d4c0cd44e32fdcf6cc9e39b2416ade"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2475996,
                    "digest": "sha256:f617bf8af0912672e16ed61332d6e7ad1f0ffc4fffe049da45ea670a1c441afd"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 362,
                    "digest": "sha256:0e3fabdd36281c4c1c946d09854510dc82ffd61476d62aaa474b3c64d8969ae3"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 151,
                    "digest": "sha256:9602e7831cd64261f173d4789e26f9cada67107ba1688409f7781bd737792b58"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 32,
                    "digest": "sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1"
                }
            ]
        }
    },
    {
        "Ref": "docker.io/paketobuildpacks/builder:tiny",
        "Descriptor": {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "digest": "sha256:e5b4e4e720598e905baa793a94259ee75827949a6ba22a3d3196eb332e475dd6",
            "size": 9773,
            "platform": {
                "architecture": "amd64",
                "os": "linux"
            }
        },
        "SchemaV2Manifest": {
            "schemaVersion": 2,
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "config": {
                "mediaType": "application/vnd.docker.container.image.v1+json",
                "size": 64488,
                "digest": "sha256:94a3f804e111904682577130709e0cac6e0541e6b1931c1f9aa4f27326c974fc"
            },
            "layers": [
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 29589398,
                    "digest": "sha256:38496a9cab3e2bb43fa8ae1d45c3ddc1d2f89328e1f3973f029949b8cb2dd5fe"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 247,
                    "digest": "sha256:2e7826560210e2f0d4249f9ea20651fecd45306c2482767274c8c37289c23788"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 316,
                    "digest": "sha256:6013ff26a0374342ff4848b3171ddbe396413d80faa2b1ee67ca9afbfa64cafc"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 106179950,
                    "digest": "sha256:87196f2fd40c0ee5587ff771878aad41b42c1d29628c75fff9206b5c0b77f016"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 188,
                    "digest": "sha256:d61afba38b8e093dfc46b8e81c141b2d7eddc0903b0fc530b3af36a46a144af7"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2744757,
                    "digest": "sha256:856e5ee7330534a520c3fd1d90260e9a5e99bfc182e0c2c3b18f7fea06f0bb0e"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 807,
                    "digest": "sha256:7eededf5887404e40dfc0d1d533fb9db3fe6b725213e4f3edda1ca1f5b1492c4"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 197,
                    "digest": "sha256:357fefdf9bc907107a38600cf8d79c713346dc97370273d1aa79635d97a2f6f9"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 9753557,
                    "digest": "sha256:d0d113e4e2bd21dbaa2f66e687ec4a23e4e83331b7845b85d0c10de1da05b08d"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2574003,
                    "digest": "sha256:41869a3aefd1a5bf8db003eb401d1af5ef2568c92262c3038f553d38145f36a1"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2573999,
                    "digest": "sha256:053ee41df41d6484ffec64fda64937a6418a1404f602487019fccddbad2958de"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 4641532,
                    "digest": "sha256:0fec499a25de5a35aa814bed46943a93c94d0e6785eedc679874ec3da04bc748"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2525673,
                    "digest": "sha256:c7b3308e13d3f30bde70d2293590aefdb95e52784b8bb840e13c587d354604e6"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 8714351,
                    "digest": "sha256:51918c870f73c8ceffc527e79041e08d3101beeabd0c0bc44555b6faf1188cdd"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3197061,
                    "digest": "sha256:fbb9179cbbb1aa191e9ec19e77b7e6226b97ba8ac9d382822970ddcc61ce05e2"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2661004,
                    "digest": "sha256:38876f988da32a7ef093d5245f6923bb9b748362834345a3e8995f72ef49e168"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2547018,
                    "digest": "sha256:b847bb2fe3fdc6bd69cd7d690bcef5a1399310ce17bea49bbd1d5fd3641d0140"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3291941,
                    "digest": "sha256:78b11fcb7ca30ba09defc8dcfc1298ea20b970430d9836b4bc7c404840b49a03"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3255182,
                    "digest": "sha256:18ee4cd834fc95727859c15eaedc1f5670c4e9f3f74e3f45a108d5b9167344ab"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1576728,
                    "digest": "sha256:ad443f24b1ed77880e534a0c1aca0ca5a722e866b7611a85e9fd7ef3463dea08"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1511595,
                    "digest": "sha256:a6cd17527f03923a723839bdbe57ec200a008de6c8b35c0c4d900a675adac014"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2689335,
                    "digest": "sha256:cd146e648d04aaf6161526eb8be96d3bf9c8fc22e433c4e6834dc972b4f09830"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3478686,
                    "digest": "sha256:bf32d3cbc5fb2d1c54c54f964b11e10d70c58f340dc17857d45db246807bcca6"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2639800,
                    "digest": "sha256:c505716a4281aec3fc577e417a29d23a19d1ff720f498aef49b9ed362ab53d88"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3382413,
                    "digest": "sha256:17c8e16edff8afd8ef3b3b1d1d061351245287c59c6ab8846c1af94b414e1865"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 555,
                    "digest": "sha256:57bf259ba83920a4e2575582423c084670209a37fdb503fbbc7e10d75a5419d0"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2798929,
                    "digest": "sha256:e71af6bec187b3f6627f52f6f2808c6b946b5cc09b7f4a6ee006cc5557254ebc"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1678930,
                    "digest": "sha256:fcf29a1baad8cb3d657d685b47ab630602a5c47b333f7ed9d7cbcae68a300801"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1826608,
                    "digest": "sha256:fad10dc586613d133e71639507d157251d8d533d9c94c3897ed5ae6c557bcdf7"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2637303,
                    "digest": "sha256:bc22ffea56cce18044465269f6958bfb8ef37e182c82c6ab9f2821525c034717"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1623998,
                    "digest": "sha256:63fd16f5b2cc4af356f18b61281870994919fcb17f3a51f490fc09b6cd5e0cfe"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3091878,
                    "digest": "sha256:71dea8ea27aab08e92be2cb1c61ba12693f8dc622575cd9087e689fdabd048fd"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 8496432,
                    "digest": "sha256:547d0874d2b5a13d766fc98a54725cce8b5ec50af624d5c21b971ca0e668d7e0"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2644647,
                    "digest": "sha256:27bd211db33f03f1ad558807c8312a3bf537e154b591f7067a7eab8d9364f10b"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 5318,
                    "digest": "sha256:3455451f8d3fd909057c5f94d9c34b5618fa6f62db51ed540cd7931c146a5fd6"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3472177,
                    "digest": "sha256:a77b05080df7a983ee586813839673e2dfdb852c87589ddf0900517bc928b779"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 8659224,
                    "digest": "sha256:6a58fb7cc75d73d08a6d85d995ad767e5693c4afd8b4f94f89f61018a3925c67"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 5136,
                    "digest": "sha256:437d9ac90cf3a6df605fbc9b691455242c3f4d7a3ba89b683daa5885314f1909"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 4385434,
                    "digest": "sha256:52814f0ca0c9d85074d817b558ccb3583cdb394d1ec02cf3e45e860b24ef3f7b"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 1838119,
                    "digest": "sha256:7e8facf10ccafea1b9688a4a4ba424d36f92e3e4cea1e913577bb45eb5bdc5f9"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 2464280,
                    "digest": "sha256:b8531cb5032999225be8589ab8bec5ea275fffb47353863c29d1afcdf7966104"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 3468583,
                    "digest": "sha256:55e985d488da8faeaa9772b7cfb3073d458fa626c89a390b292ab879be30f157"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 214,
                    "digest": "sha256:7d37e76963e86dbc76a9cbd3a6afa21c127bb790f77415b608da57daa9019f10"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 187,
                    "digest": "sha256:3aaaa9c943efae7533b9a28a28a676354866cad58208bcd7988b055c754653f0"
                },
                {
                    "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
                    "size": 32,
                    "digest": "sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1"
                }
            ]
        }
    }
]

validation

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 -

I’m using SNAPSHOT, because YOLO, but RC2 is already available!

Add a profile to the pom.xml, that will use the multi-arch builder that we created above.

# Remove the last line of the pom.xml file (on Mac OS X)
sed -i '' -e '$ d' pom.xml
# Add the new profile to the end of the pom.xml
echo "
  <profiles>
    <profile>
      <id>dashaun</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
              <image>
                <builder>dashaun/java-native-builder-multiarch:7.37.0</builder>
              </image>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>" >> pom.xml

Now your project will use the multi-architecture builder that created.

optional

To watch, and be amazed, by the correct images being pulled down to your machine, run these commands to remove any unused images from your machine.

docker kill $(docker ps -q)
docker system prune -a --volumes

build on AMD64 or ARM64

The magical moment! You can do this from AMD64 or ARM64.

./mvnw -Pnative,dashaun spring-boot:build-image

You should have an image created. One layer of that image, is a statically linked binary for your architecture.

inspect the new image.

# find the local image
docker images | grep demo
# Look at the architecture for the image
docker inspect demo:0.0.1-SNAPSHOT | jq '.[0].Architecture'

The | jq.[0].Architecture can be replaced with | grep Architecture if you don’t have jq installed

run and test the image

Run the OCI image with docker to start up the server. It should start quickly!

# Forward the port, 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

Thanks

Finally

I want to hear from you! All of my social links are here at dashaun.com.

Issues and feedback can be left in the GitHub dashaun/java-native-builder-multiarch repository.

A new builder for Spring Boot 3 RC1 on ARM64

DaShaun — Thu, 10 Nov 2022 11:18:05 +0000

Background

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

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

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

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

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

Finally

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.

Spring Boot StackPath Terraform

DaShaun — Tue, 25 Oct 2022 16:19:03 +0000

This is another article based on recent Spring Office Hours sessions. Spring Boot provides several effective ways to deliver applications, to production, efficiently. There are many situations where one of the hyperscale cloud providers is not an option, or the best choice.

Previously, I looked at Kamatera.This time, I’m going to use StackPath.

I did the work during a live stream, so you can see exactly how easy and exciting this was.

Initial Thoughts

I figured that going down this path would get easier with each provider. So far that has been true. I’m learning more about Terraform and getting more comfortable. I’m able to map the different concepts and building blocks a little easier with each rep.

Getting an account

As you would expect, nothing out of the ordinary when trying to setup an account. I couldn’t find a free tier or discount code, but I didn’t look very hard.Reach out to me if you know of something that I can share. Billing info is required.

Stackpath Terraform Provider

Having a Terraform Provider is what I have set as the bare minimum for this exercise. The StackPath Provider was surprising. I consider myself a slightly above average Terraform user. I have never experienced this as the default behavior for a Provider and I am impressed.

The provider only required three arguments for configuration. I decided to use the environment variable approach rather than passing in variables.

STACKPATH_STACK_ID
STACKPATH_CLIENT_ID
STACKPATH_CLIENT_SECRET

For the STACKPATH_STACK_ID I used the stack slug from the DASHBOARD. I created the STACKPATH_CLIENT_ID and STACKPATH_CLIENT_SECRET from the API ACCESS option of the dashboard.

When I ran the terraform plan and terraform apply they were so fast I thought it was broken. I had guessed at the value to use for STACKPATH_STACK_ID and figured that I must be doing something wrong. Nope. Their platform API defaults to an async behavior that doesn’t wait for object creation to be completed. Instead, your actions complete, and you can run terraform refresh to get the status of its creation.

I’ve used other Providers that provide this as an option. In this case, while I was learning and iterating frequently, it felt amazing.

Terraform Init, Terraform Apply via StackPath Provider - asciinema.org

asciinema.org

To check on the status I used terraform refresh and in this mode, it felt like the right way to do things.

Terraform Refresh via StackPath Provider - asciinema.org

asciinema.org

Accessing the service felt snappy.

Using Curl to Validate Workload deployed to StackPath - asciinema.org

asciinema.org

Cleaning up, was just as fast, so iterating through the struggles was relatively painless.

Terraform Destroy via StackPath Provider - asciinema.org

asciinema.org

Struggle

I spent a bunch of time not realizing that I needed the stackpath_compute_network_policy to allow public traffic. On this platform, ports are not exposed to the public by default. Even though I struggled, this made me feel a little more secure. Simply because I am forced to be specific about what I’m allowing. Additionally, the container doesn’t have remote access enabled by default.

Differences

Deploying a VM that can run Docker is one thing. Deploying a container to a platform is a different pattern. While I was wondering through the documentation, I was very interested. There are some very advanced and mature capabilities available. This is clearly a platform that is designed to support short-lived and very dynamic workloads.

Summary

I only scratched the service here, but it worked, and it worked quickly. There are some very interesting architectures that can be accomplished with StackPath and I’m excited to go further. I didn’t know what to expect on this journey. I can say that StackPath his raised the bar for my expectations going forward.

Your Turn

Take the repository for a spin and try it out for yourself. Let me know what you think.

Spring Boot Kamatera Terraform

DaShaun — Mon, 24 Oct 2022 16:19:03 +0000

Recently, during the Spring Office Hours, we have been discussing Spring to Production as a topic. There are so many ways to get Spring Boot application to production. If your Spring Boot application is delivered as a container, all you really need is a Docker or Kubernetes dial tone.

In this post, I’m starting from nothing, and delivering a Spring Boot application to Kamatera. I’ve never used Kamatera before this, so I’m going document the entire process, and experience, for you.

Getting an account

Kamatera provides a 30-Day Free Trial which sounds wonderful! After validating my email address, I was required to add a billing profile. This makes sense. However, before signing up for the free trial, I did verify that there was a Terraform provider for Kamatera.

While I was adding my billing profile, I saw more details of the 30-Day free trial.

30 days Free Usage:
1 Cloud Server (of up to 100 USD)
1000 GB Cloud Block Storage
1000 GB Outgoing Internet Traffic

This is plenty to work with, so I continued to proceed. The only option I had was to use a credit card. The process was pretty painless and only took a couple of minutes.

The UI is easy to understand and navigate. I just don’t want to use the UI. I want to automate all the things. Now that my account is set up, I want to set up my infrastructure as code.

Kamatera Terraform Provider

A quick glance at the Terraform Provider for Kamatera usage guideand I see that I need:

KAMATERA_API_CLIENT_ID
KAMATERA_API_SECRET

In the Kamatera console I easily found where I needed to go to add keys.

I clicked the + Create New Key button. A description box is presented. I put Spring Boot to Production with Kamatera in the description and clicked Create Key to move forward. At that point, I am provided with my Client ID and API Secret which I then copy to a safe place.

The Terraform Provider for Kamatera usage guide also provided an example Terraform file. I copied that and separated their main.tf into different files, that makes things easier for me to understand later. I started a github repository to capture my changes.

At this point, I determined that I couldn’t configure Docker as an option via Terraform using one of their images. They have a tool that generates Terraform files, but the image ID never worked for me. I didn’t spend much time investigating, probably user error.

That is ok, because I can use an executable JAR and deploy that as a service. Or I can just install Docker as part of the startup scripts.

I chose to use Ubuntu and their 22.04 64bit_optimized image.

Docker

I attempted to install Docker using the startup_script value of the kamatera_server but I struggled with getting that to work consistently. The problem appeared to be timing. I’m still unsure about when the startup script gets executed. I needed to wait for the network, then wait for DNS, and sometimes it would just fail. I couldn’t figure out a way to access the logs during the build process either. At one point, a server appeared to have been built and completed successfully, but the startup script was stuck in a loop, waiting for something. I couldn’t access the server though, and my Terraform was stuck, for 15+ minutes.

Interesting Side Note Regarding The Stuck Server

I opened a ticket, asking for the server to be destroyed, for two reasons. When I cancelled the stuck Terraform apply my local state didn’t show the server, so I couldn’t Terraform destroy it. In the Kamatera console, the task was showing completed, but the server didn’t show up in my server list, so I couldn’t delete it from there either.

The response was quick, less than 30 minutes, but confusing.

Unfortunately, we do not provide support for Terraform.

The Terraform Provider that I’m using, appears to be created by Kamatera and shows up in the Terraform Registry. Therefore, I can only assume that the 30-day support is not going to troubleshoot Terraform related issues.

I later realized that every server creation and destroy sends out an email receipt. I did not get a receipt for the server creation, so maybe, hopefully, their system cleaned it up properly, automatically.

Docker via remote-exec

I don’t recommend this approach. Nobody recommends this approach. The Terraform documentation states Use provisioners as a last resort.It’s marked Important and highlighted at the top of the page.

Well, it is my last resort. The purpose of this exercise was to show that getting Spring to production is doable, and Spring Boot makes it really easy. Different providers are going to have different pain points, but also, different strengths.

At this point, I use the remote-exec provisioner to do a few things:

Download the Docker install script via curl
Execute the install script
Pull down the image
Run the image on Docker

Using remote-exec required setting up a connection to the host. For this example, I chose to use a public/private key pair for access.

Execute

In order to take this for a spin yourself:

#clone the repository
git clone https://github.com/dashaun/spring-boot-kamatera-terraform
cd spring-boot-kamatera-terraform
# configure Terraform with your credentials
export KAMATERA_API_CLIENT=...
export KAMATERA_API_SECRET=...
export TF_VAR_ssh_public_key="$(cat ~/.ssh/id_rsa.pub)"
export TF_VAR_ssh_private_key="$(cat ~/.ssh/id_rsa)"
# Initialize Terraform to pull down the provider
terraform init
# Validate your credentials config by using the plan
terraform plan
# Apply the Terraform, ETC < 5min
terraform apply -auto-approve
# Access the Spring Boot application using the newly created server
curl $(terraform output -raw public_ips):8080/actuator/health | jq .

When you are done, clean up behind yourself:

# Destroy the Terraform, ETC < 1min
terraform destroy -auto-approve

Summary

While exploring multi-cloud architectures, I really wanted to get outside my comfort zone. Things like Terraform and Spring Boot make getting applications up and available really simple. I am going to continue to explore and experiment with other cloud providers. Soon, I will deploy a reference architecture, with different Spring Boot services, each deployed to different cloud providers. My theory is that you don’t have to be a certified Azure|GCP|AWS cloud architect to be productive with Spring Boot.

Feedback

I did not harden this deployment, and I wouldn’t call it production ready. If you would like to see me expand and harden this example, please let me know, via the GitHub repository.

DEV Community: DaShaun

Multi-Architecture Spring OCI from anywhere with Paketo

Multi-Architecture Spring OCI from anywhere with Paketo

Emotionally Invested

Getting Started

Docker Desktop Configuration

Option 1: Using tonistiigi/binfmt

Option 2: Using multiarch/qemu-user-static

Spring Boot 3.4.0 application

Create a multi-architecture OCI Image

Inspect

Building Native Images

Building Multi-Architecture Native Images

Inspect Native

Conclusion

Keep Learning

Spring Health Assessment Report

Links

Five Months in the making, multi-architecture builder

Long-overdue version of multi-architecture buildpack with Spring Boot 3 AOT processing support for M1, Raspberry Pi, ARM64

Upstream progress

Several failed attempts

Motivation

The work

A huge surprise

Next steps

Feedback welcome

Teamwork makes the dream work for this multi-architecture builder.

Teamwork makes the dream work for this multi-architecture builder

So close

Inspect with ARM64

Inspect with AMD64

Spring Cloud Gateway 4.0.0-RC2 native example with Testcontainers

Spring Cloud Gateway 4.0.0-RC2 native example with Testcontainers

Spring Cloud Gateway

Multi-architecture buildpack

Building and testing native images

Thanks

Keep Learning

Cloud Native Buildpack for ARM64 and AMD64

Version 7.41.0

Links

Roadmap

Feedback welcome

K3s Knative Ubuntu Raspberry Pi

K3s Knative Ubuntu Raspberry Pi

Install Ubuntu Server

Upgrade the stuff

Fix cgroup

Install k3s via k3sup

Deep breath

Knative Serving with Kourier

SSLIP.IO and a Spring Boot 3 native application

Summary

Keep Learning

Spring Boot 3 Buildpacks with Testcontainers Cloud

Background

The origin story

It sat on the back-burner and fire is hot

Momentum

The Goal

Build Spring Boot 3, native OCI images, with buildpacks, during demos, faster, with Testcontainers Cloud

Prerequisites

Login to your account

Create an application example

Write the test class

Verify

Summary

Links

First attempt at a multi-arch buildpack for Spring Boot 3

Docker manifest

Create a new manifest list

inspect the manifest list - the builder

validation

optional

build on AMD64 or ARM64

inspect the new image.

run and test the image

Links

Thanks

SSLIP.IO and a Spring Boot 3 `native` application