Platform now added in manifest for platform specific images

[pbo-linaro]

From an x64 machine,

$ docker run -it --rm --pull always docker.io/arm64v8/debian
Error: choosing an image from manifest list docker://arm64v8/debian:latest: no image found in image index for architecture amd64, variant "", OS linux

Same when trying to run an amd64 image from an arm64 host.
This used to work until very recently (~ weeks), and I suspect the image is now built with an explicit --platform parameter on your side.

Even though it's possible to explicitly add a --platform on our side, it used to be very convenient to not have to do it for cross compilation scenarios and multi stage builds involving multiple architectures. It's definitely a niche usage though.

Was this changed recently?
What was the rationale?

[yosifkit]

Yes, this happened with docker-library/meta-scripts#93. We finally have switched all our builds over to buildkit, so they now include attached provenance (the item with unknown os and architecture in the image index). (Similar issue in docker-library/python#933)

$ docker run -i --rm gcr.io/go-containerregistry/crane manifest arm64v8/debian | jq .
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:e2554fa0cd89eec5865aef4bf094c8d646059d37c42b44a6655839ea46ef3f90",
      "size": 1041,
      "platform": {
        "os": "linux",
        "architecture": "arm64",
        "variant": "v8"
      },
      "annotations": {
        "com.docker.official-images.bashbrew.arch": "arm64v8",
        "org.opencontainers.image.base.name": "scratch",
        "org.opencontainers.image.created": "2024-11-12T00:55:54Z",
        "org.opencontainers.image.revision": "dde41269a09feb7d5b046133bdd54c918ecbf1ca",
        "org.opencontainers.image.source": "https://github.com/debuerreotype/docker-debian-artifacts.git#dde41269a09feb7d5b046133bdd54c918ecbf1ca:bookworm",
        "org.opencontainers.image.url": "https://hub.docker.com/_/debian",
        "org.opencontainers.image.version": "bookworm"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:75a53f5cf6b17ed7544a6de47a5a405a0fb20abb4fb0795e4ad13fe6dd5d6536",
      "size": 840,
      "platform": {
        "os": "unknown",
        "architecture": "unknown"
      },
      "annotations": {
        "com.docker.official-images.bashbrew.arch": "arm64v8",
        "vnd.docker.reference.digest": "sha256:e2554fa0cd89eec5865aef4bf094c8d646059d37c42b44a6655839ea46ef3f90",
        "vnd.docker.reference.type": "attestation-manifest"
      }
    }
  ]
}

[pbo-linaro]

Thanks for the confirmation!

What's the goal to restrict the platform this way?
It's already obvious for which platform arm64v8/image or amd64/image is made. And beyond doing cross architecture images, I don't see the point of those images (vs normal debian image, already published for various platforms).

[LaurentGoderre]

Im curious as to why you are using the architecture namespace instead of docker run -it --rm --pull always debian or docker run -it --rm --pull always docker.io/debian

[pbo-linaro]

This is a multi-stage build involving arm64 and amd64 images to provide a container combining wine (arm64) and qemu-aarch64, to run this on amd64 hosts. see this change.

But now we have to explicitely add platform parameter, probably it's better to switch to official debian image. It was just convenient to have those images per architecture with different names.

[tianon]

My main use case personally for the per-architecture images is to avoid the "vector matching" behavior and get an exact match -- for example, if I do docker pull --platform linux/arm/v6 debian:bookworm, it will succeed, but I will transparently receive the linux/arm/v5 image because Debian does not explicitly support v6 and most (all?) v6 hardware can successfully run v5 binaries/images. If I were to instead do docker pull --platform linux/arm/v6 arm32v6/debian:bookworm, I will get the 404 I might've expected (and I want both behaviors in different contexts -- ideally this would be part of the --platform flag itself, but so far that's not implemented yet).

[cavokz]

I was hit by this issue as well. I'm used to do the equivalent of docker pull riscv64/alpine:3.20 on a Linux amd64 with qemu and binfmt, this allows to transparently execute any image.

I actually do it for a bunch of Alpine platforms:

• 3.20: riscv64
• 3.19: amd64
• 3.18: amd64
• 3.17: ppc64le
• 3.16: arm64v8
• 3.15: arm32v7

However I'm hitting this problem only with 3.20/riscv64 (logs) and 3.17/ppc64le (logs), arm64 and arm32 still work nicely.

[pbo-linaro]

As you'll need to start adding --platform parameter when running and building images, It's probably time for you to migrate to official alpine images instead of docker architecture ones. Once I did the --platform change, switching to official debian worked seamlessly.

[cavokz]

I get that adding --platform is the way forward but I'm greatly confused by "official Alpine images" vs. "Docker architecture ones". I thought I was already using official Alpine images, how --platform helps with that?

[pbo-linaro]

Using --platform=linux/riscv64 docker.io/alpine instead of docker.io/riscv64/alpine.

[yosifkit]

All the architecture specific repos as listed in the readme are official images as much as the empty namespace (aka library/) is. The library/ images are just the combination of the arch-specific images and have the same content. We actually push to the arch-specific repos first and then combine them to form the multi-architecture images in library/.

[pbo-linaro]

@yosifkit Yes, but now platform is embedded into it, what's the point to use those images vs official ones with --platform? It has become useless.

[yosifkit]

Like @tianon's comment, the arch specific repos are still useful to avoid the platform vector matching that is used when pulling multi-arch images. In other words, to guarantee getting a specific architecture or an error. The platform flag is asking for an image compatible with the supplied architecture, not exactly one specific architecture.

For example, say the arm64v8 image for a new release of php:9.0.0 is slow or failing to build, but the arm32v7 image succeeds. Then the multi-platform index is created without arm64v8. If a user pulls the php:9.0.0 image with --platform linux/arm64/v8 it will still succeed but they will get an arm32v7 image. (Note that this should only happen on a brand-new image tag, but can also happen if that architecture never existed for that image/tag, like debian:* and arm32v6).

[pbo-linaro]

Thanks for mentioning that. However, from your first answer on this thread, it seems like the change was not intentional, and a side effect of building with buildkit.
I still think it would be much more useful to not have platform embedded, and let the user decide what they use, independently from their host platform. After all, when you pull arch/image, you know exactly which image you are trying to pull already.

[tianon]

You're correct that we don't love that this changed for us -- right now we can't easily fix it due to complexities in our deployment pipeline, but we hope that someday we could consider doing so.

Either way, it's definitely recommended to be explicit about --platform even when pulling an explicitly single-platform image (especially as a signal to the runtime that you really did mean to run a "foreign architecture" image intentionally and this wasn't a mistake).