Repository navigation
[tracking] multi-architecture support #487
Description
Activity
I see that even though some of the linked issues have been resolved, there has been no activity on this issue. Are you still planning on updating it?
Thanks for the prompt, @agronholm . Something of a status report:
The manifest command is added (#138) and scheduled for deployment in 18.02-ce.
The "image manifest override" is noted by @agronholm in #327 as being referenced but not implemented with the experimental
--platformswitch.#392 refers to Notary support, which appears to be very well stalled.
#183 was solved back in November 2017.
Now with the manifest command done, the only thing holding me back from properly using multiarch images is the hard coded restriction that disallows switching to a different architecture. Is containerd still a problem in this regard, or is this only waiting for the restriction to be lifted in dockerd code?
@agronholm - the issue open still that I see on containerd is
which I've added to this master list. Is that what you were looking at, or is there something different? 2029 tries to address the question of multi-arch images running on multi-arch runtimes (e.g. a runtime that supports both 32 and 64 bits trying to pick a "correct" container image).
I am not concerned with the logic to pick the correct image for me. I'm concerned with the ability to tell docker to pick a particular architecture for the image. Qemu with binfmt support will provide compatibility. This actually used to work pretty well until Docker started telling me it can't find a compatible image when I point it to an ARM only image.
My use case is that I have a CI server and I need to produce an image of the software for both x86-64 and ARMv7. The most convenient way would be to have an identical Dockerfile and simply switch the arcthitecture as necessary with the
--platformswitch. Agreed?Right now I'm using Resin's ARM images for building the ARMv7 version, but this is not ideal.
I wish I knew enough about Docker's internals to argue :)
It just sounds like #327 is a narrowly scoped alternative to--platform. All it really needs to do is to download a specific image based on the given platform and not stop me from running it. As for the builder, the only change needed is to make sure it tags the resulting image appropriately.Hi,
Any progress to report ?
I would like to sign my manifests from docker buildxDocker v29 and up now use the containerd image store as a default, providing native multi-platform support for pulling, pushing, and building images;
- https://docs.docker.com/engine/storage/containerd/
- https://docs.docker.com/desktop/features/containerd/
We remove
docker trustsupport from the CLI; #6603, but with native multi-platform support, BuildKit provides attestations, provenance, and image identity; more / improved integration is still on the roadmap, but I think we can close this ticket.Reacted by William Desportes
This is a tracking issue for multi-architecture support.
"it would be good to open an issue that lists all the missing features as a checklist."
Since the split of Docker into components (cli, moby, linuxkit) some of the discussion about multiarch support has dispersed; this is one attempt to identify related PRs and issues that span project boundaries.
From docker/cli the following issues and PRs are relevant to multiarch support:
Cross-link to tracking issues elsewhere TBD.