[tracking] multi-architecture support

[vielmetti]

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:

• [x] Add manifest command #138
• [ ] Image Manifest Override #327
• [ ] Docker Content Trust for docker manifest Command #392
• [x] build natively on the cross compile architectures #183
• [ ] multi-arch images on multi-arch runtimes https://github.com/containerd/containerd/issues/2029

Cross-link to tracking issues elsewhere TBD.

[agronholm]

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?

[vielmetti]

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 --platform switch.

392 refers to Notary support, which appears to be very well stalled.

183 was solved back in November 2017.

[agronholm]

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?

[vielmetti]

@agronholm - the issue open still that I see on containerd is

https://github.com/containerd/containerd/issues/2029

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).

[agronholm]

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.

[agronholm]

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 --platform switch. Agreed?

[agronholm]

Right now I'm using Resin's ARM images for building the ARMv7 version, but this is not ideal.

[vielmetti]

Docs missing for node platform constraints #619 looks relevant as well, if I understand your use case.

[agronholm]

I'm not sure I understand what #619 is about. Right now the --platform switch only allows switching the operating system, not the CPU architecture, and I don't quite understand why.

[dnephin]

Because setting the CPU arch would be a lie. The builder only supports running on the current arch (GOARCH). The OS switch is there because the windows builder will support more than one OS.

It sounds like issue #327 is what you want.

[agronholm]

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.

[williamdes]

Hi, Any progress to report ? I would like to sign my manifests from docker buildx