Hi, ARM64 support was already requested and confirmed as a conclusion of #3586, but official releases of Dgraph haven’t been included. It would be awesome if the Docker images of Dgraph would be cross-compiled and included in the manifests so they work on ARM64 out of the box.
What you wanted to do
Run Dgraph on my Raspberry Pi 4 K3s cluster. I believe that the enthousiasts (like me) that want to try out Dgraph might just have an ARM server or cluster at home which requires ARM64 binaries or images.
What you actually did
Currently, I made a pipeline over at Gitlab that compiles to ARM64 and stores a Docker image. That image seems to work on my Raspberry Pi 4’s as a demo cluster. See:
It’s better to have a single “official” source of cross-compiled images in a single manifest. I’m for instance not sure what the compiled binary expects on the system, which is why I don’t know if I can get away with a clean alpine image with the binary dropped in in the long run. (e.g. user rights, folder structure, etc.)
Any external references to support your case
My custom setup uses Docker buildx: Overview of Docker Build | Docker Docs
I would be happy to submit a PR that mimics this, but as this influences your release process (and I usually work with Gitlab pipelines) I’m not entirely sure how this should work.
The most important binary by far is the dgraph one itself, as ratel should be able to run remotely and tap into your database. Compiling ratel was also slightly more tricky in my limited attempt. I think an initial PR for the dgraph binary only would already go a long way!
That seems a bit of a far-fetched use-case to be honest (you would have to design a complete app around this, and somehow maintain a server running on some device that travels throughout the world). Completely different issue, which naturally needs this compilation issue to be completed first ;).
ARM in general is making a good name for itself as far as architectures go and the Go language used to build Dgraph has cross-compilation built in. It does take some effort rewriting the current CI/CD pipelines and optionally finding some ARM hardware for that. Docker buildx may be a short-term alternative to emulate ARM64, too. Also, I wouldn’t mind opening up my three piece RPi4 cluster for some initial CI/CD testing.
Here’s to hoping this gets picked up soon! I think it would be great for enthusiasts to start tinkering on their Raspberries with it.
Bumping this issue up as dgraph does is not working on latest t4g instances that AWS has launched with Graviton2 processors based on Arm64. There are other instance types that AWS has launched along with t4g based off Graviton2. This should make enough of a case for this to be fast tracked.
A bit of a delay. Recently we decided to focus more on Linux, and given M1 Macs are the only commercially available Arm64 machines (outside Gravitons), there’s gonna be a bit of a delay
With the latest version of Go, I can happily announce that Dgraph builds and runs. (again, official support is not really there yet, I am speaking on personal capacity)
It would be a shame if ARM64 support was on hold. I really want the k8s operator working on my ARM64 Raspberry Pi 4 only cluster (k3s). I have other databases running on it, but I’ve been moving toward DGraph at work, and I can’t play around with it at home unless it runs on my cluster, since that’s the only thing with enough storage for my graph data.
arm64 is essential as cloud providers launch more arm64 enabled instances that are actually cheaper. as for developers working on Apple Silicon it would also make sense.
I compiled master on an Apple M1 but upon starting dgraph alpha it throws errors that some server running at port 2000 stopped working
With everything else on arm, Ratel is the only missing piece.
Arm enables cheaper servers, and also, M1 macs are hugely popular.
Releasing ratel docker images for arm should be prioritized.