Closed lincolnthalles closed 6 months ago
Indeed, this is a quirk of some of our build updates -- we can't provide provenance / attestation data without switching from a raw image manifest to an image index, which means they have proper platform specifications and thus the --platform
needs to be specified correctly (even on the per-arch repositories, where it wasn't previously necessary except for Windows-based images).
I'm not sure what your intent with so many FROM
values is -- can you elaborate a bit on the use case? Why are they all effectively --platform=$BUILDPLATFORM
? Why not simply FROM busybox
with an appropriate --platform
flag instead (FROM --platform=linux/arm/v7 busybox:1.36
for example)?
Indeed, this is a quirk of some of our build updates -- we can't provide provenance / attestation data without switching from a raw image manifest to an image index, which means they have proper platform specifications and thus the
--platform
needs to be specified correctly (even on the per-arch repositories, where it wasn't previously necessary except for Windows-based images).I'm not sure what your intent with so many
FROM
values is -- can you elaborate a bit on the use case? Why are they all effectively--platform=$BUILDPLATFORM
? Why not simplyFROM busybox
with an appropriate--platform
flag instead (FROM --platform=linux/arm/v7 busybox:1.36
for example)?
I was trying to achieve cross-compilation with --platform=$BUILDPLATFORM
.
Some distro images, and even architecture-targeted repositories are using arm32
, and newer Busybox images are tagged with just "arm".
Looks like a big part of the issue is the tags for arm32/v5-v7 are mismatched between image versions and Docker doesn't do any sort of normalization or tries to fallback to aliases. And to make things worse, users can tag platforms in different ways (arm and arm32, for instance).
I was able to get newer Busybox arm32 images using FROM --platform=linux/arm/v6 busybox:1.36 as target-arm32v6
. This compatibilizes Busybox's current platform layout with mine.
I figured it's also possible to remove --platform
entirely, or even use a single FROM busybox:1.36
by changing buildx to use exactly the same platform layout current Busybox images are using, but using multiple FROM
's allows changing some images to Alpine, for example.
This is a working sample (calling buildx with --platform=linux/arm32v5
and derivations):
FROM --platform=${BUILDPLATFORM:-linux/amd64} gcr.io/distroless/static:latest as distroless
FROM busybox:1.36 as target-386
FROM busybox:1.36 as target-amd64
FROM --platform=linux/arm/v5 busybox:1.36 as target-arm32v5
FROM --platform=linux/arm/v6 busybox:1.36 as target-arm32v6
FROM --platform=linux/arm/v7 busybox:1.36 as target-arm32v7
FROM busybox:1.36 as target-arm64
FROM busybox:1.36 as target-ppc64le
FROM busybox:1.36 as target-riscv64
FROM busybox:1.36 as target-s390x
# Select appropriate base image.
FROM target-${TARGETARCH}${TARGETVARIANT}
COPY --from=distroless /usr/share/zoneinfo /usr/share/zoneinfo
COPY --from=distroless /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
# Copy proper application binary.
COPY build/backend/linux_${TARGETARCH}${TARGETVARIANT}/app /opt/app/
It's not consistent, but it's working.
Anyway, I appreciate your help, and thanks for your time.
Only 386 and amd64 have consistent manifests and works in all cases, and for all image versions.
Builds using Busybox 1.35 and 1.36 are consistently failing for:
The following Dockerfile only succeeds for
386
andamd64
:By removing
--platform=${BUILDPLATFORM:-linux/amd64}
, 1.35 and 1.36 build succeeds for386
,amd64
,arm64
,ppc64le
,riscv64
,s390x
, thougharm32v5
,arm32v6
andarm32v7
still fail:Version 1.34 succeeds for all architectures, with and without
--platform
:This mixed syntax gets the most recent images I'm able to use:
This is a multi-stage cross-platform build, and this syntax works fine for Debian and Alpine (with the exception of arm32v5, which Alpine doesn't support). I also checked each built image with
uname -m
and it shows the expected architecture.