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
Comments
@estesp Is there anything remaining for this issue with Engine 1.10 shipped and fat manifest support? |
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 |
@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 Thanks! |
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 |
For "arm", just using GOARCH isn't necessarily granular enough -- for
example, ARMv7 images will not work on ARMv6 or ARMv5 boxes (generally).
Are there any plans in the works to address this?
|
Oh scratch that -- that's the manifest lists you linked to already. 👍 |
@estesp thanks for the update! |
I use armhf images to build Debian packages in my CI. |
@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/. |
@stevvooe sorry, I thought that armhf/ are experimental images made by someone from Docker team. |
@rtsisyk No worries. I just want to make sure you get your question answered! |
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)
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)
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)
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
andos
) 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
The text was updated successfully, but these errors were encountered: