I have a multi-platform image on DockerHub.
Let’s assume for simplicity that it’s amd64 and aarch64 platforms.
Let’s say the image (with tag) is called myuser/myimage:mytag
Now, I would like only to build amd64 image and replace the amd64 part of the image on dockerhub, leaving aarch64 the same as it was.
It all goes under the assumption that I can build my image locally for amd64 (with buildx and without) and I have the access to the myuser
docker hub account.
The reason to do it:
I build quite complex images both for amd64 and aarch64 platforms.
The result image for each platform has many tags and these tags are actually the versions of software ended up in the image, like python-3.9.10
.
These tags might and probably will be different for these architectures.
I want to update DockerHub images independently in build processes for amd64 and aarch64.
The easiest way for me would be to create an image if it doesn’t exist, and update (or add) only the necessary part if it already exists on DockerHub.
Note: If I for example use docker build ...
+ docker push ...
(under host amd64 machine) or use docker buildx build --platform=linux/amd64 --push --tag ... .
, it completely overrides the image and the previous aarch64 image is lost.
2
Answers
For the ones, who are interested in this question. I ended up building
aarch64
andx86_64
images independently (using self-hostedaarch64
GitHub runners). I also added anarch
prefix for all the tags to be able to pull only one particular image.And then I saved the images and tags as GitHub artifacts and then pulled two images and all the tags in one place and merged them properly using
docker manifest
command.Here how is merging works: merge_tags.py I also wrote an article to describe how I did it with more explanation: article.
Typically you would build all platforms for a single tag at once with tooling like buildx, e.g.:
If you really want to take the content from tag a, copy it to tag b, and replace the image for one architecture with new content, regclient/regctl recently added that functionality, but I wouldn’t recommend it for this purpose just because it feels like an anti-pattern. With that disclaimer, the commands look like: