make: add support for building multi-arch image manifest#508
make: add support for building multi-arch image manifest#508vyasgun wants to merge 1 commit intocontainers:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vyasgun The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
6b2e714 to
3423a91
Compare
Builds separate images for amd64 and arm64, creates a manifest of the images, and pushes the multiarch manifest to the registry Signed-off-by: Gunjan Vyas <vyasgun20@gmail.com>
9ca1b2d to
ecac20c
Compare
|
This relies on |
| image: | ||
| ${CONTAINER_RUNTIME} build -t quay.io/crcont/gvisor-tap-vsock:$(TAG) -f images/Dockerfile . | ||
| ${CONTAINER_RUNTIME} build --arch amd64 -t $(IMAGE)-amd64 -f images/Dockerfile . | ||
| ${CONTAINER_RUNTIME} build --platform linux/arm64 -t $(IMAGE)-arm64 -f images/Dockerfile . |
There was a problem hiding this comment.
Why is this not:
${CONTAINER_RUNTIME} build [--arch amd64|--platform linux/amd64] -t $(IMAGE)-amd64 -f images/Dockerfile .
${CONTAINER_RUNTIME} build [--arch arm64|--platform linux/arm64] -t $(IMAGE)-arm64 -f images/Dockerfile .to be more consistent in the way this is written. I think you might experience issues between steps that the image downloaded is architecture specific, and therefore needs to be removed to be correctly handled.
As this seems to assume, it was build from an Arm-based machine.
Note: this will also build for one of the architectures using emulation, as the images/Dockerfile performs a RUN make. This can be slow and not according to what we normally do for 'secondary architectures' (only allow native builds or cross compilation).
There was a problem hiding this comment.
Maybe try if a make cross and create for --arch --platform and a cp -a would work? This might be a way to actually prevent it to 'run' the image under virtualization/emulation.
There was a problem hiding this comment.
I still believe this is the wrong approach. This could work for development, but not for release.
For a release, the process can run on a native runner; perform a native build with the Dockerfile, aggregate files in a job and publish the manifest.
There was a problem hiding this comment.
ideally we would be building on native runners/… May not be that hard using https://github.com/gbraad-dotfiles/upstream/blob/main/.github/workflows/reusable-build-and-push-containers.yml#L43-L76
However, the container image we use at the moment hasn’t been updated in 2 years, so (in my opinion) any automation is an improvement, even if it involves qemu-user-aarch64.
We can also do this in multiple steps, do something that works, and then remove the use of the emulation code. Or delay this by a few days, as if we can finish crc-org/snc#1052 then the container image is no longer that useful.
gbraad
left a comment
There was a problem hiding this comment.
Since this pushes to a public endpoint, this is a release process.
This solution does not get my preference as it involves emulation.
|
For now; let's focus on crc-org/snc#1052 as that can remove the need for this container image. There is still a Note: |
There was a problem hiding this comment.
Pull Request Overview
This PR introduces multiarch support by building separate images for amd64 and arm64, creating a manifest for these images, and pushing the manifest to the registry.
- Adds an IMAGE variable and new build commands for both architectures.
- Implements manifest creation, cleanup, and push steps.
|
With crc-org/snc#1052 merged, we no longer need this. |
Builds separate images for amd64 and arm64, creates a manifest of the images, and pushes the multiarch
manifest to the registry