New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-arch support for docker daemon registry interface #15866

Closed
estesp opened this Issue Aug 26, 2015 · 11 comments

Comments

Projects
None yet
6 participants
@estesp
Contributor

estesp commented Aug 26, 2015

This issue will be used as a synchronization point between docker/distribution PRs and core Docker changes required to implement the multi-architecture support between registry schema changes (to enable tagging with information like arch and os) and smart parsing of fat manifests on the daemon side during pull.

Also, a design for fat manifest creation (which may need to be different than basic docker push) will be discussed here, and, as needed, PRs will be created to implement these capabilities.

References

Completed work

  • docker/distribution#912 - moves current schema to specific versioned package to make schema2 implementation work possible
@icecrime

This comment has been minimized.

Contributor

icecrime commented Feb 17, 2016

@estesp Is there anything remaining for this issue with Engine 1.10 shipped and fat manifest support?

@estesp

This comment has been minimized.

Contributor

estesp commented Feb 17, 2016

I'll close @icecrime as I think we don't need a "collector" issue anymore as all the various base PRs went in without even being tracked through this issue anyway 👀 :) The last bits are fine to handle post-1.10 in their own PRs

@estesp estesp closed this Feb 17, 2016

@bradrydzewski

This comment has been minimized.

bradrydzewski commented Feb 18, 2016

@icecrime @estesp wondering if there is an issue I can subscribe to, or any information you can provide regarding when the registry will take platform / architecture into account for pulling and pushing images? Or does it already do this now?

Specifically when I can do something like docker pull foo:latest from arm and docker pull foo:latest from amd64 (same image name and tag) and the registry will return the appropriate image for the host machines architecture

Thanks!

@estesp

This comment has been minimized.

Contributor

estesp commented Feb 18, 2016

The pull side has an initial implementation here (which made it into Docker 1.10): https://github.com/docker/docker/blob/master/distribution/pull_v2.go#L602-L622

As the note from @aaronlehmann shows, there is additional work to handle the richer platform construct that exists in the schema2 definition of a "manifest list" object.

What that leaves is the push side of the equation which we are working on with the distribution team now (with the hope of a 1.11 timeframe for availability). The general concept is described here (with all the appropriate caveats about no guarantees on specifics until there is an agreed to PR/design): https://gist.github.com/estesp/e8128058e02526d95acf

@tianon

This comment has been minimized.

Member

tianon commented Feb 18, 2016

@tianon

This comment has been minimized.

Member

tianon commented Feb 18, 2016

Oh scratch that -- that's the manifest lists you linked to already. 👍

@bradrydzewski

This comment has been minimized.

bradrydzewski commented Feb 18, 2016

@estesp thanks for the update!

@rtsisyk

This comment has been minimized.

rtsisyk commented Feb 25, 2016

I use armhf images to build Debian packages in my CI.
Could you please also add armhf/centos and armhf/fedora?
Thanks!

@stevvooe

This comment has been minimized.

Contributor

stevvooe commented Feb 25, 2016

@rtsisyk Multi-arch support is still in its infancy. I am not sure that this is the right venue for your request. I think you'll have to contact the maintainer of armhf through https://hub.docker.com/r/armhf/.

@rtsisyk

This comment has been minimized.

rtsisyk commented Feb 25, 2016

@stevvooe sorry, I thought that armhf/ are experimental images made by someone from Docker team.

@stevvooe

This comment has been minimized.

Contributor

stevvooe commented Feb 25, 2016

@rtsisyk No worries. I just want to make sure you get your question answered!

vielmetti added a commit to vielmetti/node-red-docker that referenced this issue Oct 13, 2016

Dockerfile for ARMv8 support for Node-RED
This Dockerfile adds ARMv8 support for Node-RED, using the aarch64/node support. Please note from that distribution:

THESE IMAGES ARE VERY, VERY EXPERIMENTAL; THEY ARE PROVIDED ON A BEST-EFFORT BASIS WHILE moby/moby#15866 IS STILL IN-PROGRESS -- PLEASE DO NOT USE THEM FOR ANYTHING SERIOUS OR IMPORTANT (aside from the important task of CI for testing Docker itself, which is one of their primary purposes for existence)

librae8226 added a commit to linkgo/node-red-docker that referenced this issue Dec 13, 2017

Dockerfile for ARMv8 support for Node-RED
This Dockerfile adds ARMv8 support for Node-RED, using the aarch64/node support. Please note from that distribution:

THESE IMAGES ARE VERY, VERY EXPERIMENTAL; THEY ARE PROVIDED ON A BEST-EFFORT BASIS WHILE moby/moby#15866 IS STILL IN-PROGRESS -- PLEASE DO NOT USE THEM FOR ANYTHING SERIOUS OR IMPORTANT (aside from the important task of CI for testing Docker itself, which is one of their primary purposes for existence)

mckartha added a commit to syntechdev/node-red-docker that referenced this issue Aug 7, 2018

Dockerfile for ARMv8 support for Node-RED
This Dockerfile adds ARMv8 support for Node-RED, using the aarch64/node support. Please note from that distribution:

THESE IMAGES ARE VERY, VERY EXPERIMENTAL; THEY ARE PROVIDED ON A BEST-EFFORT BASIS WHILE moby/moby#15866 IS STILL IN-PROGRESS -- PLEASE DO NOT USE THEM FOR ANYTHING SERIOUS OR IMPORTANT (aside from the important task of CI for testing Docker itself, which is one of their primary purposes for existence)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment