DEV Community: DaShaun

Two DGX Sparks, One Model: DeepSeek-V4-Flash with a 1M-Token Context

DaShaun — Tue, 15 Sep 2026 17:09:15 +0000

I got some new hardware.

Two NVIDIA DGX Sparks. I connected them to each other with two QSFP cables, and put both of them on my Tailscale network.

A single Spark has 128 GB of memory, shared between the CPU and the GPU. That is a lot of memory. It is also not the point. I did not buy two of them to run two copies of the same small model. I wanted to run something that needed both nodes.

NVIDIA even has a playbook for running vLLM across two Sparks. Follow the steps, pick a big model, done.

Easy, right?

Well, eventually.

I got it working. DeepSeek-V4-Flash is running across both Sparks with the full 1,048,576-token context. It was not as easy as I hoped, so I made a repo to keep track of what I did: dashaun/deepseek-v4-flash-2x-dgx-spark.

This post is the story behind that repo.

The rules I set for myself

Before I started, I decided on a few constraints:

vLLM and Ray run in Docker containers. Nothing gets installed on the Spark hosts.
The head node is one Spark, and the worker node is the other.
The model has to need both nodes. Tensor parallelism across the two GPUs, over the QSFP link.
Everything is driven from my Mac over SSH. No logging in to each node and typing commands in two terminals.

I did this work in a long session with Claude Code driving the terminal, while I made the decisions. That turned out to be a good fit for this kind of project: lots of reading docs, checking logs, and trying the next thing. It also meant that when something failed, we stopped and figured out why before changing anything.

Picking the model

My first instinct was "the latest DeepSeek."

The latest one, DeepSeek-V4.1-Flash, needs about 614 GB of memory at its released precision. The only full-weight DGX Spark setup I could find uses four Sparks. There is a community 2.9-bit quantization that squeezes it onto two, but that means a different base image and very aggressive quantization.

So I settled on DeepSeek-V4-Flash (the 0731 release): a 284B-parameter mixture-of-experts model, 13B active, about 156 GB of weights. Too big for one Spark. Just right for two.

Picking the container image

The NVIDIA playbook uses the NGC vLLM container. My plan was to use the newest NGC image.

It did not take long to find out that nobody runs DeepSeek V4 on a DGX Spark with the stock images. The GB10 (compute capability 12.1) needs kernels that just are not in them.

The community has done a lot of work here. I went with eugr/spark-vllm-docker and its spark-vllm-b12x image, which has a recipe for exactly this model on two Sparks. I pinned the image by digest, so both nodes always run identical bits.

eugr's tooling defaults to running without Ray. I wanted Ray, and I wanted nothing copied onto the hosts, so I wrote my own start.sh, stop.sh and status.sh that drive both nodes over SSH. They run docker commands on each Spark and install nothing.

Two cables, four links

Here is something I did not expect: two QSFP cables show up as four RoCE devices on each Spark.

Each physical port appears twice, once for each of the GB10's PCIe connections. So rocep1s0f0 and roceP2p1s0f0 are the same cable.

That matters, because NCCL has to be told which devices to use. I ended up writing network.sh, which reads everything from both nodes (ports, devices, IPs, MTU, the RoCE v2 GID index) and checks it. It doesn't change any host settings; it just tells you what you have and whether it's right.

With all four devices in use, an NCCL all-reduce between the nodes measured 145–185 Gbit/s, over RDMA, not TCP. Later load tests showed traffic split evenly across all four devices.

It works! (the first time)

The first full start took about four and a half minutes: load the weights (156 GB total, split across both nodes), compile, capture CUDA graphs. Then the API came up.

vLLM's --max-model-len auto picked the full 1M-token context. A single request ran at around 41–52 tokens per second, and eight concurrent requests reached 88 tokens per second in total.

I thought I was done.

It doesn't work (the second time)

Before sharing anything, I wanted to prove the whole thing survives a clean stop and start.

It did not.

The second start failed while warming up the model, with an assertion deep in vLLM's DeepSeek-V4 attention code:

assert active_topk_width >= cm.max_seq_len // self.compress_ratio
AssertionError

It turned out this start had about 3 GiB less memory available for the KV cache than the first one. So auto quietly shrank the context from 1,048,576 to 937,472 tokens, and part of the attention code still assumed the full length.

Same machines. Same image. Same settings. Different result.

I pinned the context at 524,288 tokens and it started cleanly. Half the context, but stable.

The OS update surprise

Then I ran sudo apt update and sudo apt upgrade -y and rebooted both nodes.

The upgrade pulled in DGX OS OTA 7.6.0 and a new kernel: 7.0 instead of 6.17. Everything below the kernel stayed the same (driver, ConnectX firmware), and all four links came back healthy.

A reboot also taught me that nothing restarts on its own. The containers are left "Exited", and ./stop.sh && ./start.sh brings everything back.

Chasing the 1M context

I really wanted the full context back, so I pinned --max-model-len 1048576 and tried again.

This time vLLM refused to start. The KV cache needed 10.06 GiB, and it had 10.03 GiB.

30 MiB short.

The fix I reached for was to give vLLM a bigger share of memory, so I raised --gpu-memory-utilization from 0.85 to 0.87.

That froze both Sparks.

SSH stopped answering. Ping went from under a millisecond to several seconds. After 30 minutes of waiting, they needed a hard power cycle. The kernel logs from that boot showed endless "Under memory pressure" messages right up until they stopped. I am just glad nothing got corrupted.

That was the most important lesson of the whole project: on a DGX Spark, the GPU and the operating system share the same memory. A memory setting for the GPU is also a memory setting for the OS. At 0.87, vLLM gave the KV cache 16.6 GiB and left the machines nothing to breathe with.

The fix: stop letting it guess

After the power cycle, I looked at what else was running on each node. The desktop (GDM, GNOME, Xorg) was using about 0.8 GB, so I turned it off. I will never use a desktop on these machines.

But freeing host memory was not the real fix. The real problem was that vLLM measures how much memory it can use for the KV cache at startup, and that measurement moved around a lot:

Five starts, same settings, anywhere from 9.66 to 16.6 GiB. The 1M context fit on some of them and not on others.

vLLM has a flag for this: --kv-cache-memory-bytes. Instead of measuring, it uses exactly the size you give it. I set it to 11G, enough for one full 1M-token request plus about 9% headroom, and well below the sizes that had run stably.

Every start now behaves the same.

Did the 1M context actually work?

Configured is not the same as working, so I tested it with real long prompts.

129K-token prompts: about 63 seconds to the first token.
Four 129K-token prompts at once: the slowest waited 228 seconds. The prompts are processed one after another, so the waits stack up.
A 904,911-token prompt: 12.2 minutes to the first token, then 42 tokens per second. No errors, and the server stayed healthy.

Free memory on both hosts stayed above 8 GB the whole time.

The full 1M-token context works end to end.

Why I made a repo

By the end I had scripts, a network checker, a load tester, a memory-sizing rule, and a list of things that had bitten me. Next time I rebuild these nodes, or someone else tries the same thing, I don't want to rediscover all of it.

So I wrote it down: dashaun/deepseek-v4-flash-2x-dgx-spark.

It includes:

start.sh, stop.sh, status.sh: bring both nodes up and down from one machine, with nothing installed on the hosts.
network.sh: discover and verify the QSFP/RoCE setup, and write the right settings into the config.
loadtest.py: concurrency and long-prompt tests, with per-cable RoCE traffic.
A README with the measured results, the memory-sizing rules, troubleshooting for every failure above, and links to all the sources and community projects I leaned on.

It is experimental. It was tested on one pair of Sparks, it depends on a community container image with a vLLM development build, and the API has no authentication. The README says all of that up front.

What I learned

Two QSFP cables are four RoCE devices. Use all four, and verify them before you blame the model.
The newest model is not always the right model. Start from what fits.
Stock images are not enough for new hardware. The community builds the good stuff first. Use it, credit it, and pin it.
Test a clean restart before you celebrate. My first success hid a problem that only showed up on the second start.
On unified memory, GPU memory settings are OS memory settings. Be conservative, and don't nudge them "just a little" on a live system.
Don't let the runtime guess when you can tell it. A fixed KV cache size turned "sometimes works" into "always works."
Write it down. That is what the repo is for.

If you have a pair of DGX Sparks, give it a try, and let me know what breaks.

A note on how this post was edited

I finished editing this blog post using OpenCode and DeepSeek V4 Flash, running on the exact setup this post describes.

DeepSeek V4 Flash and OpenCode work so well together that I dropped my two $200/month subscriptions (Claude and Codex) and switched to a $200/year subscription and a $20/month subscription instead. The savings are real, and I'm getting better results.

In about two years, this will have paid for itself. Until then, I'm going to be token-maxing to get the most bang for the buck.

Spring AI + AGENTS.md Repository Steward

DaShaun — Tue, 01 Sep 2026 21:56:22 +0000

I have been having a lot of fun building spring-ai-agents-md.

Let me back up.

I had two motivations for creating this starter.

First, I am an AAIF Ambassador. I needed to do some Ambassador'ing. I wanted to make a public contribution that tied directly to an AAIF project and helped developers understand it, try it, and build something useful with it. AGENTS.md was the obvious choice for me.

Second, I am building agents with Spring AI. I want to be able to build my own "Claude" or "Codex" with Spring AI, and I am getting closer all the time.

I work with the popular coding agents. I am also building my own agents and agent harnesses. I do not want a completely different instruction format for each one. AGENTS.md is a simple, open specification that works across those worlds. The same repository instructions can help the agents people already use and the agents I am creating with Spring AI.

I really like that.

The idea seemed simple enough.

AGENTS.md gives coding agents a predictable place to find the instructions for a repository. Spring AI gives Java developers a consistent way to build AI applications. I wanted to bring the two together.

Put an AGENTS.md file in a Spring project. Add a starter. Build a normal Spring AI ChatClient. Let the agent get the right repository instructions automatically.

Easy, right?

Well, mostly.

Phase 1: Make the simple thing simple

The first goal was a Spring Boot starter that loads an AGENTS.md document and adds it to Spring AI requests through a CallAdvisor.

I did not want to invent a schema. An AGENTS.md file is Markdown. People should be able to organize it in whatever way works for their project. The library preserves the complete document, including headings, lists, tables, code blocks, whitespace, and line endings.

The starter handles the wiring. This is the dependency:

<dependency>
    <groupId>io.github.spring-ai-community</groupId>
    <artifactId>spring-ai-starter-agents-md</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

Then you build the ChatClient like you normally would.

@Bean
ChatClient chatClient(ChatClient.Builder builder) {
    return builder.build();
}

The auto-configuration attaches the advisor to the auto-configured builder. There is no special advisor registration required in the application.

That part felt really good. It was the Spring experience I wanted.

Precedence was the hard part

Loading one file was not the biggest struggle. Precedence was.

What happens when a repository has more than one AGENTS.md file?

Which instructions apply to a file deep inside a project? Does the closest document replace the root document, or do the instructions accumulate? What happens when two documents disagree? What happens after a filesystem tool moves the agent into another part of the repository?

I did not want the answers to be whatever felt right to me that day.

Luckily, the proposed AGENTS.md v1.1 clarification arrived at the right time. It put names around the behavior I needed: jurisdiction, accumulation, precedence, and implicit inheritance.

The rules are intuitive once they are written down:

An AGENTS.md file applies to its directory and everything below it.
Applicable guidance accumulates from ancestor directories.
The closest instructions take precedence when guidance conflicts.
Explicit user instructions override file-based instructions.
Instructions from sibling directories do not apply.

The proposal is still a proposal, and the library says that clearly. But it gave me a solid target to implement and test instead of leaving the most important behavior implicit.

For a target file, spring-ai-agents-md walks toward the repository root, collects the applicable documents, and supplies them broadest first. Each complete document is kept intact inside a small framework-owned context envelope that explains the precedence.

repository/AGENTS.md
        |
        v
repository/examples/AGENTS.md
        |
        v
repository/examples/steward/AGENTS.md
        |
        v
repository/examples/steward/src/RepositoryTools.java

That final file gets the accumulated guidance, with the closest applicable instructions winning when there is a conflict.

When an application already knows the target, it can be explicit:

chatClient.prompt()
    .advisors(AgentsMdAdvisorParams.target(
        Path.of("src/main/java/com/example/Example.java")))
    .user(request)
    .call();

Filesystem tools can also propagate the path they accessed. The advisor resolves the instructions again on the next pass through the tool loop. That is the part that made the final example possible.

I wanted to be able to see what was happening

I really wanted observability in this project.

When an agent gives a surprising answer, I need to be able to debug it. Did the advisor find an AGENTS.md file? Did it find one document or several? Did discovery stop at a safety limit? How much context did I add to the prompt?

Without that feedback, every problem starts to look like a model problem.

At the same time, an AGENTS.md file can contain repository details that do not belong in logs, metric tags, or exception messages. I wanted useful visibility without copying the instructions into another system.

The starter uses Spring Boot's normal logging configuration. At DEBUG, it reports the selected resource location and character count. It never writes the contents of AGENTS.md to the logs.

When an ObservationRegistry is available, the advisor emits a focused Micrometer observation around the local prompt augmentation step:

spring.ai.agents.md.advisor

document.state      = present | empty
document.count      = zero | one | multiple
resolution.outcome  = complete | depth-limit | document-limit | size-limit

The observation does not wrap the model call or duplicate the observations that Spring AI already provides. A separate spring.ai.agents.md.context.size distribution summary records how many characters were added to the system prompt. The tags stay low-cardinality. Document contents and resource paths are never used as tags.

I also wanted sane defaults. A repository should not be able to add an unlimited number of files, or an unlimited amount of text, to every model request.

Limit	Default
Directories inspected	`32`
Documents composed	`16`
Size of one document	`64KB`
Total composed context	`256KB`

Those limits are configurable. Invalid values fail during configuration instead of surprising you later. An oversized document is skipped whole, never silently truncated. When the total-size or document-count limit is reached, composition stops while keeping the accepted documents in broadest-to-closest order.

Most importantly, the application gets feedback when that happens. The advisor publishes an AgentsMdLimitReachedEvent with the normalized target, the limit that was reached, the number of documents accepted, the context size, and the configured limit. It does not contain the document contents.

An interactive application can turn that event into immediate, useful feedback:

@EventListener
void warnAboutAgentsMdLimit(AgentsMdLimitReachedEvent event) {
    System.err.printf(
        "AGENTS.md %s reached for %s; %d documents were applied.%n",
        event.outcome(), event.target(), event.acceptedDocumentCount());
}

That distinction matters to me. A safety limit should not quietly change what the model knows. If a limit changes the context, I want to know about it. I want enough information to fix the configuration or the repository without exposing the instructions I was trying to protect.

Phase 2: Prove it with a coding agent

For Phase 2, I wanted something more convincing than a unit test and a chat endpoint.

I built the Repository Steward, an interactive coding agent built with Spring AI and Spring Shell 4.0.3.

The steward can list, search, and read files inside a bounded repository workspace. As it moves through the repository, its filesystem tools propagate the active path. The AgentsMdSystemAdvisor refreshes the applicable instructions for that path.

The architecture looks like this:

Spring Shell `steward` command
            |
            v
Spring AI ChatClient + tool loop
            |
            +--> AgentsMdSystemAdvisor
            |       refreshes instructions for the active path
            |
            +--> listFiles / searchFiles / readFile
            |
            +--> proposePatch --> pending ChangeProposal
                                      |
                         show-change / apply-change
                                      |
                                      v
                              atomic filesystem write

The model can explore the repository and propose a patch. It cannot approve its own change. apply-change is a Spring Shell command, not a model tool. A person has to review the proposal and run the command.

The safety boundaries are implemented in Java, not trusted to the prompt.

Paths must remain inside the configured workspace.
Absolute paths and .. escapes are rejected.
Symbolic links and protected directories such as .git and target are rejected.
Reads, searches, file sizes, depth, and result counts are bounded.
A patch must replace one exact, unique piece of text.
Each proposal stores a digest of the file that was reviewed.
The digest is checked again immediately before the atomic write.

If the file changed after the proposal was reviewed, the proposal is stale and the write is refused.

That is one of my favorite parts of the demo.

Was the final example necessary?

Yes.

Was it too much?

Maybe.

The Repository Steward turned a focused Spring Boot starter into a real CLI coding agent, with filesystem containment, proposal storage, diffs, atomic writes, stale-change protection, Spring Shell commands, JLine, and a lot more tests.

It also forced the model to do something that sounds simple but is not. The model has to inspect a file, preserve exact text across multiple calls, invoke a structured tool with the right arguments, process the result, and return to the conversation.

I tried a lot of models.

Some stopped after reading the file. Some printed JSON that looked like a tool call instead of calling the tool. Some invented a proposal ID. One changed the registered readFile tool name to read, which Spring AI correctly rejected. A model advertising tool support does not mean it is good at multi-step structured tool calling.

At first, I wondered if my laptop was the problem. So I ran the same workflow against larger hardware and more models. The hardware helped with speed. It did not turn every model into a reliable coding agent.

That was humbling, but useful.

The example might be more than the starter needed. It is also the best proof that the starter works. It shows AGENTS.md instructions changing as an agent moves through a repository. It shows Spring AI driving a recursive tool loop. It shows the difference between instructions for a model and safety boundaries enforced by an application.

It also made one requirement very clear: use a model that is good at multi-step structured tool calling.

Watch the Repository Steward

The video is less than one minute. It shows the steward:

Confirming its bounded workspace.
Discovering the AGENTS.md files that apply to a nested Java file.
Inspecting the implementation before answering a question.
Creating a pending patch without changing the file.
Showing the proposed diff.
Applying it only after explicit approval.

That is the story I wanted the example to tell.

Why I think this matters

I am building my own agents and agent harnesses with Spring AI. I am not sure how many other people are doing the same thing yet.

I do know that I want the instructions for those agents to live with the code. I want the format to be open. I want nested projects to provide focused context without copying everything from the repository root. I want the behavior to be easy to explain. I want the Spring integration to feel like Spring.

spring-ai-agents-md is small, but I think it is really valuable.

This has been really fun. I am really excited about this project. The tests are green, the repository is public, the example is documented, and the demo is recorded.

Now that the blog is done, let's see if I can get this pulled into spring-ai-community.

I have put a lot of work into it. I am ready for feedback, but I am still nervous.

That probably means it is time to share it.

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.

DEV Community: DaShaun

Two DGX Sparks, One Model: DeepSeek-V4-Flash with a 1M-Token Context

The rules I set for myself

Picking the model

Picking the container image

Two cables, four links

It works! (the first time)

It doesn't work (the second time)

The OS update surprise

Chasing the 1M context

The fix: stop letting it guess

Did the 1M context actually work?

Why I made a repo

What I learned

A note on how this post was edited

See also

Spring AI + AGENTS.md Repository Steward

Phase 1: Make the simple thing simple

Precedence was the hard part

I wanted to be able to see what was happening

Phase 2: Prove it with a coding agent

Was the final example necessary?

Watch the Repository Steward

Why I think this matters

Links

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

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