Skip to content
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
Closed

Multi-arch support for docker daemon registry interface #15866

estesp opened this issue Aug 26, 2015 · 11 comments
Labels
area/distribution kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny roadmap

Comments

@estesp
Copy link
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

@estesp estesp added area/distribution roadmap kind/proposal kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny and removed kind/proposal labels Aug 26, 2015
@icecrime
Copy link
Contributor

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

@estesp
Copy link
Contributor Author

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 as completed Feb 17, 2016
@bradrydzewski
Copy link

@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
Copy link
Contributor Author

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
Copy link
Member

tianon commented Feb 18, 2016 via email

@tianon
Copy link
Member

tianon commented Feb 18, 2016

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

@bradrydzewski
Copy link

@estesp thanks for the update!

@rtsisyk
Copy link

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
Copy link
Contributor

@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
Copy link

rtsisyk commented Feb 25, 2016

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

@stevvooe
Copy link
Contributor

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

librae8226 pushed a commit to linkgo/node-red-docker that referenced this issue Dec 13, 2017
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 pushed a commit to syntechdev/node-red-docker that referenced this issue Aug 7, 2018
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)
renawolford6 pushed a commit to renawolford6/red-docker-custom-node-dev that referenced this issue Oct 6, 2022
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
Labels
area/distribution kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny roadmap
Projects
None yet
Development

No branches or pull requests

6 participants