-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
distroless/static multi-arch #583
Comments
cc @imjasonh |
A few other issues referencing multi-arch from the backlog: |
Based on #346 (comment) is sounds like a multi-arch static image would be useful for Kubernetes (cc @tallclair). |
Could we do this directly in We would maybe only need docker manifest list publishing support (if we plan on this mechanism vs just explicitly tagged images) There is an arm64 debian support -- https://www.debian.org/releases/stable/arm64/ (amr64v8) |
Yes, all that should be needed is support for publishing manifest lists, and then duplicating the appropriate bits for the different architectures. This wouldn't need to solve the whole problem of orchestrating multi-arch binary builds, since AFAIK distroless doesn't include any of its own binary material into the resulting images. It would be an interesting experiment to try and produce just the arm64 flavor from the debs via a parallel set of rules. If we wanted to do this without touching |
Thanks to @dims here's what K8s needs:
From: |
@namrata-ibm I'd be happy to review PRs, but the main problem we're likely to hit is lack of Bazel support to test those platforms. If other architectures were previously using this base, then they should be able to safely return to using |
FWIW, I'd wager the bulk of this can be done via changes to: distroless/updateWorkspaceSnapshots.sh Lines 32 to 76 in 4516713
|
The distroless/static image is essentially just data:
cacerts
,tzdata
,/etc/passwd
,/tmp
. (I do see a single binary pulled in:tzconfig
, but I think ideally we'd even strip this)In
ko
, we (@jonjohnsonjr 👀 ) just landed support for multi-arch, which is based around the set of platforms available in the base image (when you pass--platform=all
). I hear thatJib
is looking into multi-arch as well.By default,
ko
usesgcr.io/distroless/static:nonroot
, which is justlinux/amd64
, but because the image itself is basically just data it actually works fine onarm64
(if forced). As a workaround for this, today I whipped up the script below to effectively "cast" theamd64
image to anarm64
image and produce a manifest list.In principle, the way most of distroless builds, it should be possible to "properly" produce the image for each architecture from the packages on the appropriate architecture mirror, but I'm a little worried about the lack of multi-arch support in rules_docker being a major blocker.
I'm sort of wondering about shipping an initial band-aid like the trick below 🥺
The text was updated successfully, but these errors were encountered: