You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wanted to continue the discussion from #28 (comment) in a dedicated issue.
So I've looked into how these new multi-arch images work.
The last time I did some work on this it seemed like the image needed to be pushed for all architectures at the same time.
This seems to be the recommended and easiest way to handle multi-arch images.
However, I found a way to build these images independently and stitch them together afterwards (see "The hard way with docker manifest" https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/). This would require us to upload each image for each architecture with its own tag to the registry, then creating a new "tag" or manifest which combines them. Afterwards the initial tags can be deleted, because their layers are referenced by the new manifest.
Interestingly, the docker manifest create command is marked experimental and not recommended for production. On the other hand, there's docker buildx imagetools create, which might work the same way.
This is the best I can come up with, yet. I don't like the fact, that we're required to push the "intermediate" images first, and I'm not sure if that's an acceptable solution. Furthermore it would increase the complexity of the task. What do you think?
I also couldn't find 1) how to improve the readability of the logs (only through --output=plain) nor 2) allow individual architectures to fail, while keeping the successfully build, as alternative solutions.
The text was updated successfully, but these errors were encountered:
This is the best I can come up with, yet. I don't like the fact, that we're required to push the "intermediate" images first, and I'm not sure if that's an acceptable solution. Furthermore it would increase the complexity of the task. What do you think?
If that's the only issue, I think it would be acceptable to push the images with a suffix in the tag (eg: :17-bookworm-arm64). That also allows those explicit images to be published when the others aren't. For example: if the 17-bookworm-s390x build fails, the 17-bookworm-amd64 image will be available, but the multi-architecture image (17-bookworm) will stay at the latest version for which all platforms succeeded.
Wanted to continue the discussion from #28 (comment) in a dedicated issue.
So I've looked into how these new multi-arch images work.
This seems to be the recommended and easiest way to handle multi-arch images.
However, I found a way to build these images independently and stitch them together afterwards (see "The hard way with docker manifest" https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/). This would require us to upload each image for each architecture with its own tag to the registry, then creating a new "tag" or manifest which combines them. Afterwards the initial tags can be deleted, because their layers are referenced by the new manifest.
Interestingly, the
docker manifest create
command is marked experimental and not recommended for production. On the other hand, there'sdocker buildx imagetools create
, which might work the same way.This is the best I can come up with, yet. I don't like the fact, that we're required to push the "intermediate" images first, and I'm not sure if that's an acceptable solution. Furthermore it would increase the complexity of the task. What do you think?
I also couldn't find 1) how to improve the readability of the logs (only through
--output=plain
) nor 2) allow individual architectures to fail, while keeping the successfully build, as alternative solutions.The text was updated successfully, but these errors were encountered: