Release Linux/ARM64 Docker Images [FEATURES]

[odidev]

Hi Team,

I am working with fluid on the Linux/ARM64 platform.

I can see that the docker images are only available for the Linux/AMD64 platform here: < https://hub.docker.com/u/fluidcloudnative >. Images are built/released via Makefile where the ‘helm’ and ‘kubectl’ binaries are hardcoded for ‘amd64’ in the Dockerfiles.

I have changed the GOARCH to arm64 in the Makefile, installed helm and kubectl for arm64 in the Dockerfiles, updated gomonkey version to 2.2.0 in the source code, and successfully built Linux/ARM64 FluidCloudNative docker images via make docker-build-all locally on the ARM64 machine.

It will be helpful if the FluidCloudNative docker images become available at dockerhub for Linux/ARM64 platform as well. Do you have plans for the same? If yes, I will be happy to contribute if required.

[cheyang]

@odidev Sure. We'd like to support arm64. You're welcome to contribute it.

@zwwhdls @frankleaf @apc999 @xieydd may I know if the runtime engine can also work in Linux/ARM64? I think controller can work fine but how about the engine? I know some engine is depending on low level code.

[zwwhdls]

JuiceFSRuntime image(>=v0.11.1) can work in ARM64.

[odidev]

@cheyang

I have prepared a commit to add Linux/ARM64 support to the source code by updating gomonkey version to 2.2.0 and replaced docker build with docker buildx to release multi-arch docker images for both AMD64 and ARM64 platforms.

Please find the changes here: < https://github.com/odidev/fluid/commit/17f669e181d8db5edd5be8e5e65502668d0b9aad >.

Docker buildx uses qemu emulator for ARM64 translation. Qemu-aarch64 translator is slow, hence it takes much time for building Linux/ARM64 docker images on the x64 host platform using docker buildx utility. It took me almost 2 hours to build fluid-dataset-controller multi-arch docker image via docker buildx utility. But the major advantage in using docker buildx utility is that we can have same image name that supports both the architectures.

An alternative to using buildx is building and pushing Linux/ARM64 docker images using docker build. But, in that case, we must create images with different names for ARM64. Also, users need to have ARM64 machines to build the ARM64 images on the host platform.

If you are interested in the docker buildx approach, I will raise the PR with the same changes as shared above. Or else, I will edit the Makefile to create separate images for Linux/ARM64, with separate names and targets for the docker build approach.

Kindly share your opinion on the same.

[odidev]

Hi Team,

A gentle reminder!!!...can you please review the commit shared in my previous comment? Kindly share your opinion.

[odidev]

Hi Team,

A gentle reminder!!!...can you please review the commit shared here? Kindly share your opinion.

[cheyang]

@odidev Thanks very much for your contribution! And very sorry for missing your latest comments. I think buildx is cool, and you are welcome to contribute.

[cheyang]

odidev@17f669e

I like the way Docker buildx uses qemu emulator : < https://github.com/odidev/fluid/commit/17f669e181d8db5edd5be8e5e65502668d0b9aad >.

And I think it may be great, if you can create several small PRs to locate different issues:

1. Update gomonkey version to 2.2.0
2. Support both build and buildx in Makefile, I like the way that both using image-nightly and image-nightly-buildx: https://github.com/juicedata/juicefs-csi-driver/blob/master/Makefile#L51-L64. . Maybe we can use build for daily development, buildx for release.

What do you think?

[odidev]

Sure @cheyang , I will soon raise separate PR for each concern. Thank you for the response.