FusionAuth / fusionauth-containers

Container definitions for docker, kubernetes, helm, and whatever containers come next!
https://fusionauth.io/
219 stars 68 forks source link

ARM64v8 - Raspberry Pi compatible docker image #49

Closed arslanakhtar61 closed 2 years ago

arslanakhtar61 commented 4 years ago

I want to deploy fusionAuth onto ARM64v8 - Raspberry Pi 4. So far the docker images for fusionAuth only support amd64 architecture. Is there a way to deploy fusionAuth docker image on Raspberry Pi 4 k8s cluster?

robotdan commented 4 years ago

Fixed!

jerryhopper commented 4 years ago

for what its worth to anyone: I've setup automation on the gitrepository, using a github-runner. See /.github/workflow/main.yml for details. https://github.com/jerryhopper/fusionauth-app-multiarch

robotdan commented 4 years ago

@voidmain -> https://github.com/jerryhopper/fusionauth-app-multiarch/blob/master/.github/workflows/main.yml

ColinM9991 commented 3 years ago

Thank you for your persistence @jerryhopper. I've recently stumbled across this as I'm also building some Docker images on RPi ARM64. Your Actions yaml file, with a few tweaks, did the trick for me.

ceefour commented 2 years ago

OMG! OMG! OMG!

image

Evidence: https://hub.docker.com/layers/fusionauth/fusionauth-app/1.32.1_multi/images/sha256-da71d5be2bc849ef9d4e1205508fa34994973d75798a47cab9a8484ee2592ff7?context=explore

So this is official?

Thank youuuuuuuuu @robotdan and @jerryhopper !!!

ceefour commented 2 years ago

Today is I think a major milestone for FusionAuth, definitely deserves a release note.

I've been running FusionAuth in Fargate (amd64) so far and it's been rock-solid, and relatively easy to deploy & manage.

AWS is (understandably) pushing its own Arm processors, and now available in Fargate:

Announcing AWS Graviton2 Support for AWS Fargate – Get up to 40% Better Price-Performance for Your Serverless Containers

When I'm not using Fargate, I use k3s in cloud servers (k3s is also great for IoT, edge devices, etc. which are usually Arm-based).

So I'm excited how this empowers users/sysadmins on choices of deployment (and cost).

ceefour commented 2 years ago

Example usage with Pulumi:

const taskDef = new aws.ecs.TaskDefinition(pulumi.getProject(), {
  family: `${pulumi.getProject()}-${pulumi.getStack()}`,
  executionRoleArn: pulumi.output(ecsTaskExecutionRole).arn,
  containerDefinitions: containerDefinitions.apply(JSON.stringify),
  volumes: [],
  memory: "1024",
  requiresCompatibilities: ["FARGATE"],
  networkMode: "awsvpc",
  cpu: "256",
  runtimePlatform: {
    cpuArchitecture: "ARM64",
  },
  tags: {
    "Environment": "prod",
    "tenant_id": "lovia",
  },
});
ceefour commented 2 years ago

I just switched a FusionAuth instance to arm64 and the transition was so smooth I couldn't even tell whether it's actually running the arm64 version. Definitely not here:

image

Amazon ECS Web UI doesn't show anything either at runtime. The only clue is the Task Definition, and even that in JSON, it doesn't anywhere else:

image

@robotdan Do you think it's a good idea to put the arch in System > About ?

Second: Since "About" also mentioned the entire Database version string... I guess wouldn't hurt to also put the entire JVM string as well?

ceefour commented 2 years ago

The downside at this point is that AWS seems to be overbooked with Graviton.

I previously used FARGATE_SPOT capacity provider in ap-southeast-1a and had no capacity issues. After switching to ARM64 it cannot provision due to undercapacity. But changing to FARGATE capacity provider works, with higher bill obviously.

But this is awesome! Choice!

robotdan commented 2 years ago

@jerryhopper I too get this error when trying to build the arm v7 image.

5 166.0 java.nio.file.DirectoryIteratorException: java.nio.file.FileSystemException: /tmp/openjdk/jmods: Value too large for defined data type

But I am building on an intel MacBook. We will be getting our M1 MacBooks shortly, so I can retry on that platform. But we currently release on an x86 Linux server. However, we could probably spin up an arm based build agent to release additional image architectures .

@ceefour

So this is official?

Hopefully soon. Just ensuring it works, but I hope to add this to the release process and all future images will be published form arm64 and amd64. And hopefully linux/arm/v7 if we can get it to work.

@ceefour in your above screen shots, can you confirm you are running FusionAuth on Graviton? And yes, that is a great suggestion to add the architecture type to the about panel.

robotdan commented 2 years ago

Arch type for the about panel -> https://github.com/FusionAuth/fusionauth-issues/issues/1531

robotdan commented 2 years ago

@ceefour how about this?

image

That is essentially just a string made up from Java properties os.name, os.version and os.arch. I think this arch value will be the Java arch, and not necessarily the underlying OS arch type. In most cases they should be the same, but not necessarily. So I may still if I can reliably also get the underlying operating system arch.

jerryhopper commented 2 years ago

a quick note from my side: i will look into the armv7 issue tonight - it previously runned here on a qemu, i will test/try again on real armv7 hardware instead of a emu.

ceefour commented 2 years ago

@robotdan that is awesome! 🔥

jerryhopper commented 2 years ago

@jerryhopper I too get this error when trying to build the arm v7 image.

5 166.0 java.nio.file.DirectoryIteratorException: java.nio.file.FileSystemException: /tmp/openjdk/jmods: Value too large for defined data type

But I am building on an intel MacBook. We will be getting our M1 MacBooks shortly, so I can retry on that platform. But we currently release on an x86 Linux server. However, we could probably spin up an arm based build agent to release additional image architectures .

As far as i know, jlink doesnt seem to import/copy the jmods for some shady reason. i have tried but somehow dont get this error. it seems to hit some kind of limit. (32/64bit?) Also im not quite familiar with your build-enviroment. (and i dont have a mac) - but i will look into it.

Wild guess: maybe specifying the arch during build helps?

FROM ubuntu:focal as build to FROM --platform=$BUILDPLATFORM ubuntu:focal as build

Building using github actions runs fine... you might want to have a look at my build-log - i have invited you to my gitproject- So you could have a look at the 'Actions/buildlogs' overthere.

On a sidenote: amv7 is merely a 'gimmick' ... the memory limitation doesnt makes it the best choice for running FA :)

jerryhopper commented 2 years ago

Maybe it is an idea to use Github Actions? - i created a workflow for that, which you can find in this branch: https://github.com/jerryhopper/fusionauth-containers/tree/jerryhopper--multi-build-githubworkflow

i had to slice the command in the dockerfile, because for some weird reason it fails if i dont split the command. Also, i had to expliciltly declare "FROM --platform=$BUILDPLATFORM ubuntu:focal as build" in the Dockerfile.

nodesocket commented 2 years ago

We also would like a arm64 version, specifically back ported to tag 1.24.0. 🙏🏻

Looks to be a work in progress only using the latest version:

Screen Shot 2022-02-02 at 6 11 10 PM

robotdan commented 2 years ago

Hmm, that may be possible. I’ll take a look.

robotdan commented 2 years ago

Done and done.

https://hub.docker.com/layers/fusionauth/fusionauth-app/1.24.0/images/sha256-fb023e73f644c114636914ab7ea1ccaeb525726cc8dcda106c01dea94469f638?context=repo

Any specific versions you want in between 1.24.0 and current? I suppose we could just republish all of them as well.

nodesocket commented 2 years ago

@robotdan just saw that it looks like you pushed up 1.24.0 with arm64 support. First of all, thank you so much. 🙏🏻 👨🏻‍🎤

Shouldn't that tag also have linux/amd64 as well though for Intel? Or does the original tag push with amd64 still get pulled in that case?

Thanks again 💯

Screen Shot 2022-02-02 at 9 06 32 PM

robotdan commented 2 years ago

Shouldn't that tag also have linux/amd64 as well though for Intel? Or does the original tag push with amd64 still get pulled in that case?

Yes.. was in the middle of testing a few things. Refresh and it should show all 3 architectures now.

Thanks again 💯

You're welcome! Thanks for using FusionAuth!

robotdan commented 2 years ago

I think I'll close this one out. I will published (or have published depending upon when you read this) images back to 1.24.0 for linux/amd64, linux/arm64 and linux/arm/v7.

Going forward all releases will be published with at least those three architectures, perhaps linux/ppc64le and linux/s390x for good measure. I don't want to leave our IBM Power and IBM z friends out.

Anyone have an opinion an y additional architectures? I see there is a linux/arm/v5 - not sure if anyone would use that? I'm not smart enough to know what that is used for, so if you want it let us know.

robotdan commented 2 years ago

Thank you so much to everyone who has provided suggestions here, helped us understand the need, for contributing examples, PRs, etc. @jerryhopper @ceefour @nodesocket @arslanakhtar61 @ColinM9991 .

We plan to put out a press release for our multi-arch support. We may add some community member quotes if anyone is interested in contributing one. If interested, use the contact form on the website and indicate @robotdan sent you for a quote. 😎

robotdan commented 2 years ago

I only released the latest patch in each point version. https://github.com/FusionAuth/fusionauth-containers/actions

If anyone needs another version for arm64 let me know.