arm64 containers - build on native arm64 runners
# 🌱|help-and-getting-started
s
Hi there, I'm building arm64 containers and the qemu builds are taking a very long time. I'm running on a k3s cluster at home. I've added a native arm64 node to it, but buildkit does not build on it by default. Is there a way to have the arm containers build on the arm node? Thank you
b
Hi @salmon-scientist-57815 thank you so much for your patience, it seems on first glance that there is a bug where we are not picking up the
deploymentRegistry
setting. At least in the config you provided in https://discord.com/channels/817392104711651328/1303760789978484746 it seems like the remote-dev environment does have a
deploymentRegistry
, and I assume you are using that environment? I'm looking into the code and will keep you posted. Can you share the full error message in the mean time, maybe with a stack trace (You can get the full stack trace using the option
-l5
)
s
Hi @big-spring-14945 thanks for the reply and looking into it. Yes I'm using a deployment registry and using the remote-dev env. Will share that stack trace
I'll DM you the file
@big-spring-14945 any insights yet? 🙂
f
Hi @salmon-scientist-57815, we took another look and think we found the culprit see this PR https://github.com/garden-io/garden/pull/6681 Once it is merged the fix will be published in an edge release that you can update to via
garden self-update edge-bonsai
. Can you give that a try?
The edge release is ready by now 🙂
s
@freezing-pharmacist-34446 Thanks for the update. It does indeed find the image now, but it ignores the
DeploymentRegistry
specified in the
project.garden.yml
and tries to push to hub.docker.com
Copy code
Failed to publish Build type=container name=signalling-server-linux-x86-64: Error: publish Build type=container name=signalling-server-linux-x86-64 failed: Error: Unable to run regctl command "image copy registry.gitlab.com/aivero/prop/workspace/signalling-server-linux-x86-64:v-9c6dab3b10 signalling-server-linux-x86-64:v-9c6dab3b10" in /home/rapha/Development/workspace/.garden/build/signalling-server-linux-x86-64: Command "/home/rapha/.garden/tools/regctl/66d14b3f0b23786d/regctl-linux-amd64 image copy registry.gitlab.com/aivero/prop/workspace/signalling-server-linux-x86-64:v-9c6dab3b10 signalling-server-linux-x86-64:v-9c6dab3b10" failed with code 1:

time="2024-11-26T20:57:36+01:00" level=warning msg="Failed to push blob" err="failed to send blob post, ref docker.io/library/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d: unauthorized" src="registry.gitlab.com/aivero/prop/workspace/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d" tgt="docker.io/library/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d"
time="2024-11-26T20:57:36+01:00" level=warning msg="Failed to copy layer" err="failed to send blob post, ref docker.io/library/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d: unauthorized" layer="sha256:5cab7a77a6666f5254f5afda40e2ea3a025a3ec6fdd1ca437e7b1c491563c120" source="registry.gitlab.com/aivero/prop/workspace/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d" target="docker.io/library/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d"
failed to send blob post, ref docker.io/library/signalling-server-linux-x86-64@sha256:42195d6a8d351a35091df362ad4a0d56344a51e56d8d7853c998a5c57a468d6d: unauthorized
Also, any progress on native builds on the arm runners without the buildx workaround?
f
Hi @salmon-scientist-57815 , sorry for the late reply. I created another PR to fix the fallback behavior to the image name including the deploymentRegistry behaviour. You can also explicitly set the
publishId
in your container build actions if you don't want to wait for that.
> Also, any progress on native builds on the arm runners without the buildx workaround? I am afraid this is not on our short-term roadmap. Once we revisit the whole topic we will probably go the buildx path ourselves, since it is more flexible and up to date than the current buildkit / kaniko approach.
s
Hi @freezing-pharmacist-34446 yes that seems to work. I had not understood that the publishId expects a fully qualified tag. However, just running the build command already pushes to the registry. Is there a way to push to a dedicated tag - e.g.
latest
or the name of the branch? EDIT: Yes its simply `garden publish name-of-action --tag latest`: https://docs.garden.io/other-plugins/container#publishing-images
f
Yes you are exactly right about that tag param. BTW i started another PR https://github.com/garden-io/garden/pull/6690 to fix a discrepancy between our docs and the actual behaviour - here https://docs.garden.io/other-plugins/container#publishing-images we state that your image registry will be taken into account by default, which wasn't true. The
publishId
is always the safe bet anyway, but yeah if you are already using a remote deployment registry that should be part of the default push target unless otherwise specified.
Hi @salmon-scientist-57815 , this PR got merged and released last week. Can you try again with the latest garden version and see if that resolves it?
s
@freezing-pharmacist-34446 will try when I touch this next. Won't be immediately. Thanks for letting me know 🙂
@freezing-pharmacist-34446 seems to work. Thank you
f
Nice, thanks for letting me know!
6 Views