inertia icon indicating copy to clipboard operation
inertia copied to clipboard

Support ARM Processors

Open chadlagore opened this issue 7 years ago • 12 comments

Is your feature request related to a problem? Please describe. The inertia daemon is not compatible with ARM processors (like my Raspberry Pi!)

ubuntu@ubuntu:~$ sudo docker run --it ubclaunchpad/inertia:v0.4.1 sh
standard_init_linux.go:190: exec user process caused "exec format error"
ubuntu@ubuntu:~$ dpkg --print-architecture
armhf

More detail on this error here.

Describe the solution you'd like We should ship an inertia daemon image that runs on alpine for the ARM microarchitecture.

Additional context I think the Raspberry Pi is a great use case for intertia 😄

chadlagore avatar Jul 16 '18 04:07 chadlagore

This would be super cool actually! Also interesting since I didn't realize there would be incompatibilities even with the docker image... I wonder, if we have to detect architecture to pull the correct image, we might as well host daemon binaries on a free object store somewhere and not use images?

I think the Raspberry Pi is a great use case for intertia

It would be! I would be very concerned with the performance of builds however 😋 perhaps #201 will provide a nicer experience for Pi-based Inertia deployments?

bobheadxi avatar Jul 16 '18 06:07 bobheadxi

I did not expect incompatibilities either. Still learning about this.

This image, compiled on AMD h/w, using arm64v8/alpine base image throws the same error. I'll try build the image on ARM h/w shortly—if that works, then a hot-fix is easy.

if my hardware is ARM:
    build inertia daemon image 
else:
   pull inertia daemon image

Otherwise we need to find AMD hardware to build and push images for releases. I can be your Raspberry Pi guinea pig 🐷

chadlagore avatar Jul 16 '18 16:07 chadlagore

Been thinking about grabbing a Pi as well... maybe this is a good excuse 😋 Thanks for looking into this!

bobheadxi avatar Jul 16 '18 17:07 bobheadxi

I've been able to run the inertia daemon image on the Pi itself by simply building the image locally on that hardware. It looks like this may be possible to do from our CI. This image now hosts an image of the inertia daemon built on ARM h/w.

chadlagore avatar Jul 18 '18 03:07 chadlagore

Seems like a painful procedure - do you have any thoughts on moving Inertia out of a Docker image and distributing the daemon as a plain binary, and using a script to detect architecture on daemon-up?

We can compile the web app into the binary as well using our fileb0x (the new equivalent of go-bindata), and host the binaries on a free Amazon S3 instance (I think they're free - if not, could always use... google drive or something 😅 )

The reason for initially going with Docker was being able to distribute a single package for all platforms - since that doesn't look guaranteed, we might not really have a reason to distribute it as a Docker image at all 🤔

bobheadxi avatar Jul 19 '18 06:07 bobheadxi

With a small diff on your travis scripts I think I can get it to build and push a separate image—if it works you don't have two separate daemon deployment strategies on your hands immediately. I'm just testing it locally right now.

This compiling js into your binary stuff sounds really cool though 😮Do you think that cross compilation will be easier than multi-stage builds in the long run? Looks simple for ARM in particular. I think we already do this kind of distribution process with the client, right?

chadlagore avatar Jul 19 '18 06:07 chadlagore

With a small diff on your travis scripts I think I can get it to build and push a separate image

That would be awesome if you can get that working, would be awesome to get another PR from you again! 🤤 I'll be getting my raspberry pi this weekend or next monday so I'll be able to try it out hopefully 🏃

Unfortunately however, even with the separate image we'll still need some platform detection in the startup script to pull the right image, as you mentioned 😓 At that point I'm thinking maybe we can skip the images and just distribute binaries as our single strategy, right?

Although as a hotfix, this is definitely acceptable

This compiling js into your binary stuff sounds really cool though 😮Do you think that cross compilation will be easier than multi-stage builds in the long run?

Not particularly - I was mostly thinking that it would be a way we could package the daemon as a single binary instead of a Docker image 🐳

Looks simple for ARM in particular. I think we already do this kind of distribution process with the client, right?

Yep! Cross-compilation for the daemon will just be a matter of making a script similar to this one and adding an entry for ARM: https://github.com/ubclaunchpad/inertia/blob/master/.scripts/release.sh#L6

bobheadxi avatar Jul 19 '18 06:07 bobheadxi

New complication: the docker/compose image isn't built for ARM hardware (obviously 😅).

chadlagore avatar Jul 24 '18 05:07 chadlagore

@_@ oh dear

a quick look at the repo though seems to reveal there's an ARM dockerfile for docker/compose, thats gotta be somewhere (or we could build ourselves... less than ideal)

there's also the possibility of Go-based docker-compose (#230, https://github.com/komuw/meli)

bobheadxi avatar Jul 24 '18 05:07 bobheadxi

Meli:

ubuntu@ubuntu:~/alfred$ curl -sfL https://raw.githubusercontent.com/komuw/meli/master/install.sh | sh
komuw/meli crit platform linux/armv7 is not supported.  Make sure this script is up-to-date and file request at https://github.com/komuw/meli/issues/new

chadlagore avatar Jul 24 '18 05:07 chadlagore

Currently building that Dockerfile :+1:

chadlagore avatar Jul 24 '18 05:07 chadlagore

re: meli, that script looks like it downloads precompiled binaries, which the author did not build an ARM binary for - you might have to go get and compile/cross-compile it. If we use it as a lib, should not be an issue (it'll get built appropriately alongside the other stuff)

bobheadxi avatar Jul 24 '18 05:07 bobheadxi