ubclaunchpad / inertia

โœˆ๏ธ Effortless, self-hosted continuous deployment for small teams and projects
https://inertia.ubclaunchpad.com
MIT License
153 stars 18 forks source link

Support ARM Processors #322

Open chadlagore opened 6 years ago

chadlagore commented 6 years ago

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 ๐Ÿ˜„

bobheadxi commented 6 years ago

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?

chadlagore commented 6 years ago

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 ๐Ÿท

bobheadxi commented 6 years ago

Been thinking about grabbing a Pi as well... maybe this is a good excuse ๐Ÿ˜‹ Thanks for looking into this!

chadlagore commented 6 years ago

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.

bobheadxi commented 6 years ago

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 ๐Ÿค”

chadlagore commented 6 years ago

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?

bobheadxi commented 6 years ago

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

chadlagore commented 6 years ago

New complication: the docker/compose image isn't built for ARM hardware (obviously ๐Ÿ˜…).

bobheadxi commented 6 years ago

@_@ 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)

chadlagore commented 6 years ago

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 commented 6 years ago

Currently building that Dockerfile :+1:

bobheadxi commented 6 years ago

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)