Support multi platform Docker build (buildx)

[janhoy]

Building on my mac (M1) I only get an arm64 build, and it does not work on intel machines. So I need to build with multi architectures. This PR enables that. (still testing)

[janhoy]

I think this is ready, can someone review?

[ksclarke]

I have a Mac now to test with. I'll get this done tomorrow before doing the new Cantaloupe release.

[janhoy]

Also, today you only push amd64 image to hub. Could you look at officially publishing arm image as well. Not just for Mac but many Linux systems now run arm.

[ksclarke]

Looking into GitHub Action arm runners.

[janhoy]

Looking into GitHub Action arm runners.

I see several explicit amd64 references in Dockerfile (kakadu) and perhaps elsewhere, so probably needs more effort if you want to take advantage of some of the native libraries being pulled in. However, wrt docker image builds, it should be fully possible to build both amd and arm images on the same runner through use of docker buildx.

[ksclarke]

@janhoy Re: "However, wrt docker image builds, it should be fully possible to build both amd and arm images on the same runner through use of docker build."

Is that right? It looks to me like the docker-maven-plugin builds the image for the platform on which the build is happening if it's one of the supplied ${docker.platforms} when more than one is supplied. That makes me think we could have a ${docker.platforms} value for all supported platforms, but that we'll need a runner for each of those platforms(?)

Cf. https://dmp.fabric8.io/#build-buildx

[ksclarke]

One of our programmers is going to look into running Mac GitHub Action runners to get automated builds (minus the Kakadu stuff) using that going.

[janhoy]

Is that right? It looks to me like the docker-maven-plugin builds the image for the platform on which the build is happening

If you continue reading on that same page, you will find that:

These rules only apply to the image built and loaded into the local image cache with the build goal. They do not apply to the push goal which will always build and push either a single-architecture or multi-architecture image with whatever platforms are specified in the element.

I.e. a developer will get a local build for her own platform when invoking "build" target. But during release, when you invoke the "push" target, buildx will build and push all architectures (using QEmu) as normal.

[ksclarke]

Just updating this ticket... The build works as a multi-arch build, but to do the deploy/release I have to replace the overlayfs in my local Docker install with a custom containerd-snapshotter config (suggested by fabric8io/docker-maven-plugin#1557 (comment) (after you go down the rabbit hole a bit)). This is a result, it seems, of docker-maven-plugin using --load in the release vs. --push.

I can do this locally (and push to DockerHub), but cannot do this on GitHub Actions (I don't think) unless I configure a Docker-in-Docker setup (or run my Actions runner as a self-hosted runner). Still working on it though...

Edit: Actually, this seems to only be a problem when also trying to do attestation (sbom/provenance) with the multiarch release.

[janhoy]

Any news on this issue last 3 months? Looks like the root problem you linked to above docker/roadmap#371 was solved, and it indeed works on my mac.

Wrt automating in github actions, I don't know if there are blockers. But I find several blogs showing it is possible, such as https://ruan.dev/blog/2024/04/21/multi-architecture-docker-builds-with-github-actions. I suppose, if we have the prerequisites setup in workflow, the final step docker/build-push-action could be replaced by mvn?

[ksclarke]

Hi @janhoy Yes, I think the blockers are resolved now. I think getting the version of Docker we need (and running it on a runner on MacOS) can be accomplished with https://github.com/docker/setup-docker-action (which I've used successfully for a personal project and it works on Macs, too). We are pretty booked up on work until mid-March, though, and there has been some talk in the cantaloupe-dev meetings about moving this project under the official IIIF-org umbrella. So, I don't have a concrete timeline to give you at this point. If I get ahead of our current project's work, I may devote a day to getting this updated and working, but that's not a firm estimate for you.

[ksclarke]

Oh shoot, well, I just looked at that link again and I see they now have a warning on the main page: "Does not work on macOS runners with ARM architecture (no nested virtualization)" with a link to two tickets so it may not be the solution I was thinking it would be. I skimmed the blog you linked, but I'll read in more detail to see if it has any additional answers.

Edit: There may still be a qemu solution(?) I was looking into that before I found the setup-docker-action above.