Closed arslanakhtar61 closed 2 years ago
Fixed!
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
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.
OMG! OMG! OMG!
So this is official?
Thank youuuuuuuuu @robotdan and @jerryhopper !!!
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:
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).
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",
},
});
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:
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:
@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?
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!
@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.
Arch type for the about panel -> https://github.com/FusionAuth/fusionauth-issues/issues/1531
@ceefour how about this?
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.
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.
@robotdan that is awesome! 🔥
@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 :)
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.
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:
Hmm, that may be possible. I’ll take a look.
Done and done.
Any specific versions you want in between 1.24.0 and current? I suppose we could just republish all of them as well.
@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 💯
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!
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.
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. 😎
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.
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?