Closed mikerimov closed 1 month ago
That's a perfect amount of detail. I think I see what's happening.
paketobuildpacks/builder-jammy-base
which is only distributed in x86 format.paketobuildpacks/amazon-corretto
, paketobuildpacks/health-checker
, and paketobuildpacks/java
, which are shipped in x86 and aarch64 format.
bdb87104...
image from paketobuildpacks/java, which is the x86 version83cfa97...
which is older and was before we released multi-arch images, so it's only an x86 image.a61ada...
from paketobuildpacks/health-checker, which is the aarch64 version.So it's based on the images that you're pulling, and the architecture on which the buildpack is running. If you were to pick a newer version of Amazon Corretto, it would have been shipped with multi-arch support so it would be running on aarch and the buildpack for it would be pulling the aarch64 binaries as well. When the buildpack runs, it simply looks at the currently running architecture, as reported by the Go runtime, and grabs binaries for that.
You can override this by setting BP_ARCH=amd64
. We really only use this for testing, but you can try in your case as it might be enough to force the buildpack into pulling x86 binaries.
The other thing you could try would be to use the buildpack hash to identify it instead of the version. docker.io/paketobuildpacks/health-checker@sha256:a61adafdb92549b9492bd87e597df0ae3733f253637f0e3be022360f28fb7fd5
. That would point to the x86 version of the image. https://hub.docker.com/layers/paketobuildpacks/health-checker/latest/images/sha256-0ec2387101f39acfd72576abd0eb22690d0e3748f5b837a8e551180f758b6027?context=explore
It's a little odd that this is happening. My expectation is that it would have seen that the builder is x86 and it would have pulled x86 for all of the other images. If this is the problem then this is not a Paketo issue, but rather the platform which in this case is the Spring Boot build tools. I would suggest you try pack
cli and see if you get the same behavior. That has a different platform implementation. I believe it works off of the builder image's architecture. If does work correctly with pack, then I would suggest opening an issue with that project.
Hope that helps!
Ok, so as soon as I bump Coretto to the latest, it starts downloading aarch64 releases too.
[INFO] [creator] Corretto JDK 17.0.12: Contributing to layer
[INFO] [creator] Downloading from https://corretto.aws/downloads/resources/17.0.12.7.1/amazon-corretto-17.0.12.7.1-linux-aarch64.tar.gz
[INFO] [creator] Verifying checksum
[INFO] [creator] Expanding to /layers/paketo-buildpacks_amazon-corretto/jdk
[INFO] [creator] Adding 137 container CA certificates to JVM truststore
BP_ARCH=amd64 DOES force download to intel images.
[INFO] [creator] Tiny Health Checker 0.29.0: Contributing to layer
[INFO] [creator] Downloading from https://github.com/dmikusa/tiny-health-checker/releases/download/v0.29.0/thc-x86_64-unknown-linux-musl
So that likely means the env calling into the buildpacks (spring-boot-maven-plugin) is misconfigured.
Final question and then lets close this:
What's the correct base builder that I should be using other than builder-jammy-base?
Thanks for peeking at this.
So scratch that, when I deployed to launch, I get
[31;1mERROR: [0mfailed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_amazon-corretto/helper/exec.d/debug-9': fork/exec /layers/paketo-buildpacks_amazon-corretto/helper/exec.d/debug-9: exec format error
I went combing through the build logs to see if I could spot anything. Which made no sense to me since the logs clearly show downloading https://corretto.aws/downloads/resources/17.0.12.7.1/amazon-corretto-17.0.12.7.1-linux-x64.tar.gz
I'm guessing maybe the executable jar layer from:
[INFO] [creator] 8 of 28 buildpacks participating
[INFO] [creator] paketo-buildpacks/amazon-corretto 8.5.2
[INFO] [creator] paketo-buildpacks/ca-certificates 3.8.4
[INFO] [creator] paketo-buildpacks/bellsoft-liberica 10.8.2
[INFO] [creator] paketo-buildpacks/syft 1.47.1
[INFO] [creator] paketo-buildpacks/executable-jar 6.11.0
[INFO] [creator] paketo-buildpacks/dist-zip 5.8.2
[INFO] [creator] paketo-buildpacks/spring-boot 5.31.0
[INFO] [creator] paketo-buildpacks/health-checker 2.2.0
Maybe is picking up the wrong thing but I feel like I'm chasing ghosts at this point. Recommendations?
What's the correct base builder that I should be using other than builder-jammy-base?
So we are working on having multi-arch support in all of the builders, but it's a slow process because every buildpack that ships with the builder needs to be packaged as multi-arch first.
In the meantime, what we've done is ship the paketobuildpacks/builder-jammy-buildpackless-tiny
builder with multi-arch support. This is the simplest one because it's the smallest number of packages and has no buildpacks by default.
This will work just fine with Java apps because most of them will run great on tiny, it just means you need to specify the list of buildpacks that you want to use in your configuration. For a Maven app, that looks like this.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<builder>paketobuildpacks/builder-jammy-buildpackless-tiny</builder>
<buildpacks>
<buildpack>paketobuildpacks/amazon-corretto</buildpack>
<buildpack>paketobuildpacks/java</buildpack>
<buildpack>paketobuildpacks/health-checker</buildpack>
</buildpacks>
</image>
</configuration>
</plugin>
Gradle is similar, with this.
tasks.named("bootBuildImage") {
builder = "paketobuildpacks/builder-jammy-buildpackless-tiny"
buildpacks = [
"paketobuildpacks/amazon-corretto"
"paketobuildpacks/java"
"paketobuildpacks/health-checker"
]
}
We're also working on a Java-specific builder, since we've updated all of the Java-related buildpacks to support multi-arch. It's early days now, but that's located here, if you're feeling adventurous.
Maybe is picking up the wrong thing but I feel like I'm chasing ghosts at this point. Recommendations?
My guess is that it's still marking something as arm64/aarch64, even though the buildpack is installing an x86 JVM. Try my previous note and build using for arm64/aarch64, that should work for you.
Oh, I forgot. If you want to build with pack
cli, there is a flag to force x86. See this thread, https://github.com/orgs/paketo-buildpacks/discussions/287#discussioncomment-9755893. That's pack specific though, so for Spring Boot Build Tools that won't work. You'd need to reach out to the Spring team and request something similar.
OK cool let's call this resolved. I finally figured out that while I was spelunking spring-boot-maven-plugin
and finding the arch arguments for individual images that wasn't the release branch, that's upcoming. (3.4?) So until the next release I'll sit on older paketo buildpacks that aren't arch aware and call it for the day. May be back next time they update. Thank you for your assistance, and I'm sorry that it turned into a tooling bug instead.
Building an Intel Image on a M1 Mac results in an aarch64 layer added to an intel image.
Current Behavior
Buildpack logs while building:
You'll see that the THC was an aarch64-unknown-linux-musl. The docker image itself would run on an intel linux deploy, but thc would fail and if you tried to run manually you'd get a "File Format Error" (Which yeah, but hey, I was trying to be complete :) )
Motivations
Current cross platform build seems to be missing something in latest THC and we had container deploys that were counting on thc to report docker status because of the file format error.
Replication Note
The one complexity here is that we were doing spring-boot-maven-plugin which makes it harder for me to write a super concise "This is how you reproduce" I'm happy to supply debug output logs etc to assist in tracking this down.