architecture and operating system support

[stevvooe]

The distribution system should support images with different operating systems and architectures. The most relevant subject matter is the ongoing manifest proposal #62). Requirements are covered in the superseded ticket but may be incomplete. They should be re-enumerated here.

Supersedes docker-archive/docker-registry#743 and docker-archive/docker-registry#648.

@estesp

[jlhawn]

To comment on this issue, it looks like the solution for this is going to be in the flexibility of the new manifest format. "Architecture and Operating System Support" isn't a registry issue - it's an application issue, specifically Docker Images.

One way that Docker images can solve this issue with the proposed manifest format is to simply use a different media type with the application data in the manifest containing a mapping of "os/arch" to the actual image manifest for that platform.

[estesp]

@jlhawn is definitely correct that the registry itself will not be dealing with os/arch issues, but per our call yesterday, there will be some inter-related operations and steps to get multi-arch support into the engine; I've updated my prior gist about fat manifests to be more specifically focused on the discussion we had in #62 around using a mediaType specific to combined manifest pointers as the path to arch/os specific content under the same repo name in v2. @stevvooe you mentioned maybe having a Google Doc to start to hash out all those details; please feel free to use this as a starting point, or comment here initially until we have that rolling.

https://gist.github.com/estesp/a3546f3cf24d2fc9cecc

[harche]

Hi,

Based on the discussions so far I have created a gist. Please let me know your thoughts...

https://gist.github.com/harche/6f29c6fe8479cb6334d2

[stevvooe]

@harche This is not really the right approach. It ruins the generality of the manifest. The manifest knows nothing about operating systems or architectures. It is a distribution structure and decoupled from docker. This leaves control in docker engine's hands and keeps this stuff out of registry code.

Checkout my comments here:

#62 (comment)

This defines "alternates", that can be labelled. This will provide a solid, backwards compatible approach. It is also efficient for the vast majority of users who only use linux-amd64. The target could be labelled, as well, so the primary target could be changed in the future.

[estesp]

Hey @stevvooe ..I just saw your comment in #62 earlier, and it does seem to make sense. First question that comes to mind is what happens to images which will never have a linux-amd64 entry? For example, I assume after Windows Server comes out with their full container capabilities and Docker support, they will want the Hub to have specific WindowsOS base images. Potentially ARM or POWER or z system stakeholders may create images which bundle software unique to that hardware or architecture (e.g. a Raspberry Pi-specific package). I assume in that case there would be no dependencies, but only alternatives, labeled for that specific os/arch?

[stevvooe]

@estesp We should have target declare the arch/os labels and make the initial handlers deal with these fields before proceeding. Is that reasonable?

[estesp]

Sure, that makes sense @stevvooe

[harche]

@stevvooe I want understand this better, I have updated #62 with my comment.

[dmp42]

cc @RichardScothern @aaronlehmann

[dmp42]

@RichardScothern @stevvooe I assume we can close this?

[stevvooe]

@dmp42 We still have an action item to define the values for the fields in platform. I think we can close this as long as there is an issue covering that omission.

[luxas]

When will this be implemented in the daemon build, push and pull commands?
Just wondering if there's concrete work at the moment...

[stevvooe]

@luxas The work in distribution has provided a way to provide platform agility in a content addressable distribution system.

The implementations in build, push and pull do have active work, but that is more about leveraging the features provided here. I'd recommend asking your question via IRC or directly on the docker project.

@RichardScothern @dmp42 We may want to close this issue. Distribution has already provided the necessary components to support multi-platform.

[bradrydzewski]

@stevvooe do you think it make sense to re-open this issue in core docker repository?
moby/moby#15866

It would be great to have a place to track overall progress and subscribe to notifications

[stevvooe]

@bradrydzewski At this point, the plumbing is there so I am not sure if a big omnibus issue is helpful. They tend to slow down as being too big or their closure criteria is unclear.

I'd recommend filing more specific issues, describing exactly what is needed yet. "Multi-platform support" is a big wide target and means many different things to many people.

I know @estesp and the Microsoft folks (@jstarks, et al.) are taking on various parts to ensure this for their various platforms, but I don't know that anyone from the arm community is driving this.

[estesp]

@bradrydzewski I wrote a blog post recently that tries to itemize what I believe is left. Caveat: this is my personal opinion as an involved party. Some of it is not related to the open source projects (e.g. DockerHub UI), but I know the engine pieces are understood, and docker pull is already partially enabled, and with the tool described in my blog, the multi-platform variant of docker push is possible against private registries (v2.2 and above) and DockerHub today. Images already self-identify with os/arch during docker build, and that information is part of what is stored in an image config in the registry, but is somewhat not necessarily part of the discussion (unless we are talking about having "cross-compile"-like behavior in docker build which I've never heard discussed).

https://integratedcode.us/2016/04/22/a-step-towards-multi-platform-docker-images/

[paralin]

What's the status of this? Anything in 1.12, or do I need to still use a different tag per arch?

Just wondering since recently it seemed it pulled a different version on aarch64 vs armhf for container4armhf/armhf-alpine:edge

I can't seem to find anywhere that specifies the status of this feature.

[dmcgowan]

@paralin support for the schema 2 manifest was added in Docker 1.10. As of docker 1.10 the engine is capable of pulling multi-platform images and the registry as of 2.3 is capable of storing them. You will not find much documentation other than the specifications currently as there are not very many multi-platform images generated and no tool within docker to generate. Docker 1.12 will not ship with any new capabilities for generating multi-platform images but will be able to pull them. Also as of this month the Docker Hub is capable of storing and retrieving multi-platform images. I suggest taking a look at the blog post in the previous comment, while there is not a tool built into docker, Phil built one and documented how to use it in his blog post.

Status summary, support added, tooling and documentation coming. Try it out, be an early adopter and send feedback.

[paralin]

Great, thanks. I will read the blog post and bravely try to use it at scale :)

[milosgajdos]

@thaJeztah this was solved by OCI index manifests, right? I think we should close this 7 years old issue 😅

[thaJeztah]

Yup! I think this was the ticket that lead to manifest indices ("multi-arch images"). Which are now common (an no longer an esoteric thing).

Closing!