bazel,rules_docker - java_image 与arm64?

发布于 2025-01-13 09:05:05 字数 2186 浏览 3 评论 0原文

我正在尝试在苹果芯片(m1)上运行((带有docker驱动程序的minikube),rules_k8s,rules_docker)。我可以使用苹果英特尔运行这个 bazel 构建。

但是当我在 m1 上运行相同的构建时,我的 java pod 因 SIGILL 而死亡。 从 pod 的日志来看,它似乎使用 java for amd64 运行(而不是 arm64)。

如何为arm64构建java_image

现在我正在使用下面的 bazel 代码。

load("@io_bazel_rules_docker//java:image.bzl", "java_image")

java_image(
    name = "image",
    runtime_deps = [...],
    jvm_flags = [...],
    main_class = "...",
)

Pod 的日志

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x000000401470c125, pid=1, tid=9
#
# JRE version: OpenJDK Runtime Environment (11.0.13+8) (build 11.0.13+8-post-Debian-1deb11u1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.13+8-post-Debian-1deb11u1, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# J 4416 c1 java.lang.String.hashCode()I [email protected] (49 bytes) @ 0x000000401470c125 [0x000000401470c100+0x0000000000000025]
#
# Core dump will be written. Default location: //core
#
# An error report file with more information is saved as:
# //hs_err_pid1.log
Compiled method (c2)   34765 2778       4       java.util.concurrent.ConcurrentHashMap::get (162 bytes)
 total in heap  [0x000000401b4fde10,0x000000401b4fe4e8] = 1752
 relocation     [0x000000401b4fdf88,0x000000401b4fdfb0] = 40
 main code      [0x000000401b4fdfc0,0x000000401b4fe280] = 704
 stub code      [0x000000401b4fe280,0x000000401b4fe298] = 24
 metadata       [0x000000401b4fe298,0x000000401b4fe2a0] = 8
 scopes data    [0x000000401b4fe2a0,0x000000401b4fe3c8] = 296
 scopes pcs     [0x000000401b4fe3c8,0x000000401b4fe488] = 192
 dependencies   [0x000000401b4fe488,0x000000401b4fe490] = 8
 handler table  [0x000000401b4fe490,0x000000401b4fe4d8] = 72
 nul chk table  [0x000000401b4fe4d8,0x000000401b4fe4e8] = 16
Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
#   https://bugs.debian.org/openjdk-11
#

I am trying to run ((minikube with docker driver), rules_k8s, rules_docker) on apple silicon (m1). I could run this bazel build with apple intel.

But when I run same build on m1, my java pod die with SIGILL.
From pod's log, it seems to run with java for amd64(not arm64).

How can I build java_image for arm64?

Now I am using below bazel code.

load("@io_bazel_rules_docker//java:image.bzl", "java_image")

java_image(
    name = "image",
    runtime_deps = [...],
    jvm_flags = [...],
    main_class = "...",
)

Pod's log

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x000000401470c125, pid=1, tid=9
#
# JRE version: OpenJDK Runtime Environment (11.0.13+8) (build 11.0.13+8-post-Debian-1deb11u1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.13+8-post-Debian-1deb11u1, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# J 4416 c1 java.lang.String.hashCode()I [email protected] (49 bytes) @ 0x000000401470c125 [0x000000401470c100+0x0000000000000025]
#
# Core dump will be written. Default location: //core
#
# An error report file with more information is saved as:
# //hs_err_pid1.log
Compiled method (c2)   34765 2778       4       java.util.concurrent.ConcurrentHashMap::get (162 bytes)
 total in heap  [0x000000401b4fde10,0x000000401b4fe4e8] = 1752
 relocation     [0x000000401b4fdf88,0x000000401b4fdfb0] = 40
 main code      [0x000000401b4fdfc0,0x000000401b4fe280] = 704
 stub code      [0x000000401b4fe280,0x000000401b4fe298] = 24
 metadata       [0x000000401b4fe298,0x000000401b4fe2a0] = 8
 scopes data    [0x000000401b4fe2a0,0x000000401b4fe3c8] = 296
 scopes pcs     [0x000000401b4fe3c8,0x000000401b4fe488] = 192
 dependencies   [0x000000401b4fe488,0x000000401b4fe490] = 8
 handler table  [0x000000401b4fe490,0x000000401b4fe4d8] = 72
 nul chk table  [0x000000401b4fe4d8,0x000000401b4fe4e8] = 16
Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
#   https://bugs.debian.org/openjdk-11
#

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

执手闯天涯 2025-01-20 09:05:05

java_image(来自rules_docker)使用图像的基本属性。
Rules_docker 中的默认基本属性是 DEFAULT_JAVA_BASE 。它实际上是@java_image_base//image

@java_image_base//image存储库()
它使用 gcr.io/distroless/java:latest (链接)。

我不得不为arm64 使用另一个镜像。


我可以通过规则 container_pull 并在 java_image 中指定 base attr 来使用 distroless/java11-debian11:debug-arm64

打造

java_image(
    name = "image",
    base = "@java11_arm64//image",
    ...
)

工作空间

container_pull(
  name = "java11_arm64",
  registry = "gcr.io",
  repository = "distroless/java11-debian11",
  digest = "sha256:2184282f01097038fcf83b86196e225ae079b973c8fe9960f8db4961c5662388",
)

java_image(from rules_docker) uses base attr for image.
And default base attr in rules_docker is DEFAULT_JAVA_BASE. It is actually @java_image_base//image.

@java_image_base//image is declared in repositories().
And it uses gcr.io/distroless/java:latest (link).

And I had to use another image for arm64.


I could use distroless/java11-debian11:debug-arm64 by rule container_pull and specifing base attr in java_image.

BUILD

java_image(
    name = "image",
    base = "@java11_arm64//image",
    ...
)

WORKSPACE

container_pull(
  name = "java11_arm64",
  registry = "gcr.io",
  repository = "distroless/java11-debian11",
  digest = "sha256:2184282f01097038fcf83b86196e225ae079b973c8fe9960f8db4961c5662388",
)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文