Support for ARM v7/Raspberry Pi 4

[afonsosantos]

Is your feature request related to a problem? Please describe. When trying to run on Raspberry Pi, the ARM CPU is not supported by some Docker requirements.

Describe the solution you'd like I would like a Docker flag/build to support ARM.

Additional context

pi@pi:~/authentik $ docker-compose pull
Pulling postgresql  ... done
Pulling redis       ... done
Pulling server      ... pulling from server
Pulling worker      ... pulling from server
Pulling geoipupdate ... done

ERROR: for worker  no matching manifest for linux/arm/v7 in the manifest list entries

ERROR: for server  no matching manifest for linux/arm/v7 in the manifest list entries
ERROR: no matching manifest for linux/arm/v7 in the manifest list entries

[BeryJu]

I thought raspbery Pi 4's were arm64? There's currently an amd64 and arm64 build as I was having issues building on older versions due to some python dependency

[afonsosantos]

Hi!

The specs from the Raspberry Pi 4 CPU are:

pi@pi:~ $ lscpu
Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500.0000
CPU min MHz:         600.0000
BogoMIPS:            108.00
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

[BeryJu]

Right, now I remember the issues

• node doesn't have a native armv7 image, only a custom built one
• python cryptography doesn't have wheels for armv7

Additionally, Pi 4's have armv8 hardware but ship with an armv7 kernel

[afonsosantos]

Armv7 is a weird arch, especially for Docker.

I've found this Docker image for Node armv7: https://hub.docker.com/r/arm32v7/node/ And also this wheel for cryptography: https://www.piwheels.org/project/cryptography/

Do you think there's something we can do with that? Thank you!

[BeryJu]

Yeah I've seen those two, the issue with the node image is that that repo only has armv7 images, so there would need to be custom dockerfiles for each arch.

For cryptography I'm looking at just installing the packages required to build it, since that'll work on all arches

[afonsosantos]

Seems like Node is the remaining problem here. No rush here, but would be very nice to run this awesome project on my Raspberry Pi at home. I've tested the project in a Ubuntu VM and it's just what I'm looking for.

[BeryJu]

Allthough looking into it, looks like the normal node docker image should support armv7 and arm64

[BeryJu]

So while armv7 builds are mostly working now, I don't think I want to support it since the builds take so long to run (over an hour through qemu-emulation), and I don't have anything to test with. I "blame" the issue more on Raspbian still being a 32-bit Operating system even though the Pi4 is armv8, when using raspbian it only uses armv7. I think it makes more sense to recommend users to use an Operating system on their Pi that allows them to use the full potential of their hardware, rather than compiling for really niche architectures (especially with the upstream support for arm/v7 dwindeling)

[afonsosantos]

Hi, I understand the issue and agree on it. I'll consider moving to another OS.

[RoboMagus]

Other than the long build times, was there any other reason for not including the ARMv7 architecture in your releases?

Though I agree with you that Raspberry PI's should just run aarch64, often due to the way people start with their setup they end up with the 32 bit OS anyway.

I have current test deployment working on my RPi 4 running 32bit Raspbian with just some minor modifications and built locally on the RPi. There seem to be no real reason Authentik could not run on ARMv7 so far, or I might miss something.

To put in my 2 cents; since there appears to be no underlying reason that prevents Authentik from running on ARMv7 I think it would be a great addition to support it anyway. If only for community adoptation, as it is a very welcome addition as an authentication service for those of us just dipping their toes in self hosting, homelab, etc.

[jarfil]

@RoboMagus If you got it to work, could you share the modifications? I'm running 64bit Raspbian on the RPi 3 and 4, but would like to try this on an ARMv7 RPi 2 (the old version).

[RoboMagus]

@jarfil. I've forked the repo and my modifictations in there are currently up to date ;) Though do note that building this on a RPi4 already takes AGES, So I'm not sure you'd want to build this on a Pi 2.

[BeryJu]

@RoboMagus The main reason I didnt want to was that last time I checked, was that you either needed to use third party wheels, or compile them during install like you're doing. While that works fine I'd prefer to not have to do that since it might create additional issues that dont exist with the wheels, and it might leave a lot of additional cruft in the image (which is already heavier than I want it to be) (also see discussion here https://github.com/matrix-org/synapse/issues/9403)

The other thing I noticed in your diff is that --platform=${BUILDPLATFORM} is related to docker buildx, which I recommend you to use aswell, see https://docs.docker.com/buildx/working-with-buildx/

The changes for MaxInt64 should be fixable by using math.MaxInt which works on 32-bit and 64-bit

[RoboMagus]

Thanks for your comment on this @BeryJu.

That removal of the buildx related argument was just a quick workaround for local builds without arguments, as i could not otherwise get it to just build using docker-compose on my Pi setup. But indeed, there should be no need to remove that and you'd still be able to build it all.

With the MaxInt issue, I read about similar issues as your latest build shows: MaxInt not declared by package math (typecheck). I figured if it's just about ensuring large enough buffer space, Int32 is already a ridiculously large number.

I'm personally fine with building the image locally and having the image not be as lean as it would ideally be. It's a shame that the cryptography package does not provide wheels for this platform though. But just in case I might run into some of them later on. What kind of issues would you expect that might be created by building the package on the fly instead of using the wheels? As far as my understanding goes, as long as it builds I would not expect compatibility issues. But I might be missing something there.

Thanks!

[BeryJu]

This might've fixed itself https://twitter.com/geerlingguy/status/1488935828625764363?s=21

[RoboMagus]

That might for sure make it a lot easier. But for existing systems that are already up and running, one would still have to perform a clean install of the OS.

[Reupireup]

This might've fixed itself https://twitter.com/geerlingguy/status/1488935828625764363?s=21

Hello, I think you should consider (my case for example) the owners of rpi4 armv7 who start using it before the 64bits release. I have allready 10+ armv7's containers running on my rpi4 (nginx, fail2ban, goacces, vaulwarden ...), I just wanted to test Authentik, but this test means to reinstall OS and reconfigure all my containers. I'll test other solution like authelia which release an armv7 version.

[RoboMagus]

@Reupireup, at the begining of 2022 I was in the same position as you describe. However I decided just to make the switch to arm64 OS anyway, as it turns out more Docker images that I am now running lack support for armv7.

This transition (at least for me) was quite painless, as any service running on the PI was deployed using Docker. So based on that experience I would not recommend against upgrading.

The alternative, as I commented way back then was to locally build it yourself, as that way the 'wheels issue' can be sort of circumvented. It does take quite some time to build all of those dependencies though...