Open synarete opened 1 year ago
Also, could we leverage make's typical target based workflows rather than an embedded shell loop? Something like:
.PHONY: image-build-multiarch
image-build-multiarch: image-build-arch-amd64 image-build-arch-arm64
$(BUILDAH_CMD) manifest inspect $(IMG)
image-build-arch-%: qemu-utils image-build-multiarch-manifest
$(BUILDAH_CMD) bud \
--manifest $(IMG) \
--arch $* \
--tag "$(IMG)-$*" \
--build-arg=GIT_VERSION="$(GIT_VERSION)" \
--build-arg=COMMIT_ID="$(COMMIT_ID)" \
--build-arg=ARCH="$*" .
image-build-multiarch-manifest:
$(BUILDAH_CMD) manifest create $(IMG)
.PHONY: image-push-multiarch
image-push-multiarch:
$(BUILDAH_CMD) manifest push --all $(IMG) "docker://$(IMG)"
.PHONY: image-multiarch
image-multiarch: image-build-multiarch image-push-multiarch
(I left out .PHONYs on my added rule names just to be a tad shorter in a gh comment)
Looks pretty good so far, I am a bit curious why it uses buidah directly rather than docker/podman. Were there features of the process that are only supported by buildah?
docker uses the docker buildx
to build multi-arch images; unfortunately, this is docker specific sub-command. I used BUILDAH_CMD
instead of CONTAINER_CMD
as it has the --manifest
and --arch
flags. With podman
it would require multi-steps build.
Also, could we leverage make's typical target based workflows rather than an embedded shell loop? Something like:
.PHONY: image-build-multiarch image-build-multiarch: image-build-arch-amd64 image-build-arch-arm64 $(BUILDAH_CMD) manifest inspect $(IMG) image-build-arch-%: qemu-utils image-build-multiarch-manifest $(BUILDAH_CMD) bud \ --manifest $(IMG) \ --arch $* \ --tag "$(IMG)-$*" \ --build-arg=GIT_VERSION="$(GIT_VERSION)" \ --build-arg=COMMIT_ID="$(COMMIT_ID)" \ --build-arg=ARCH="$*" . image-build-multiarch-manifest: $(BUILDAH_CMD) manifest create $(IMG) .PHONY: image-push-multiarch image-push-multiarch: $(BUILDAH_CMD) manifest push --all $(IMG) "docker://$(IMG)" .PHONY: image-multiarch image-multiarch: image-build-multiarch image-push-multiarch
(I left out .PHONYs on my added rule names just to be a tad shorter in a gh comment)
Fair enough. Will fix.
Removed priority-review
label because this is a draft.
I run an ARM-based Kubernetes cluster and would like to integrate the samba-operator. Is there a timeline for when this PR will be merged?
Hi @abachmann I was thinking about this topic recently after watching some devconf.us talks on youtube that were related to this subject. The issue isn't so much the samba-operator itself, as this codebase is golang and Go's got a pretty good cross compliation story. The real work needs to be done in the samba-container project we either need time or volunteers to help get us set up with multi-arch builds and manifest support for the latest tag and future release tags.
Folks who are not samba experts but know something about docker and/or podman and containers and (probably) github actions could help a lot here. I'm sure eventually one of us current maintainers at samba-containers will get around to it - especially if it becomes relevant to our downstream - but I would not be able to provide a timeline for that.
Build multi-architecture image using buildah and qemu static utilities. Creates an image with manifest which refs amd64 (x86_64) and arm64 (aarch64) architecture-specific sub-images. Using the same Dockerfile regardless of the actual CPU architecture, and let buildah+qemu do all the low-level logic.
Note: typically, qemu would emulate arm64 on x86_64 which yields longer build time.