tl;dr: It's possible, but I wouldn't recommended it just yet!
Since I've been working on some Authentication features I was looking for a way to self host & share a test Forem instance. Also for a while I've been wanting to use my Raspberry Pi more, so I thought to myself:
Elasticsearch was the first hiccup, because it only runs on 64 bit systems so I installed Raspberry Pi OS (64 bit beta version). The OS is based on Debian, so with Docker installed you can get the stack up and running locally using these commands:
# Elasticsearch ARM image :D $ docker run -d --restart=always --name es -e "cluster.name=docker-cluster" -e "bootstrap.memory_lock=true" -e ES_JAVA_OPTS="-Xmx2G -Xmx2G" -e "discovery.type=single-node" -e "xpack.security.enabled=false" -e "xpack.monitoring.enabled=false" -e "xpack.graph.enabled=false" -e "xpack.watcher.enabled=false" -p 9200:9200 -p 9300:9300 -v /opt/data/elasticsearch:/usr/share/elasticsearch/data elasticsearch/elasticsearch:7.8.1-arm64 # Postgres $ docker run --name pg -e POSTGRES_DB=forem -e POSTGRES_USER=forem -e POSTGRES_PASSWORD=forem -d -v /opt/data/pg:/var/lib/postgresql/data -p 5432:5432 --restart=always postgres:11-alpine # Redis $ docker run --name redis -d --restart=always -p 6379:6379 redis:6-alpine
Why not use the Forem Docker installation? Because everything needs to be slightly tweaked to work on ARM, hence the "don't try this just yet" disclaimer at the top.
This is where it gets tricky, because the dependencies in the actual Rails project aren't as straightforward to get right. Some of them are Ruby gems with native extensions, so you'll bump into a few errors. I found that
gcc won't compile the C code from cld, so I manually swapped it out for cld2-small in the Gemfile & Gemfile.lock.
The trick to make
mini_racer to work was to look into the libv8 (
mini_racer dependency) which actually includes the V8 binary, but they stopped releasing with
arm-linux supported binaries at
The solution: Cross reference the latest working version of
0.2.4) that uses this
libv8 version and force the Gemfile & Gemfile.lock to use these.
I didn't want to waste too much time in order to setup a production (
RAILS_ENV=production) version of the app, the idea was to just make it work so I could test and share a public link for others to test using my Raspberry Pi. So I'm running the app using
foreman start -f Procfile.pi and that custom Procfile looks like this:
web: bin/rails assets:precompile && bin/rails s -p 3000 sidekiq: bundle exec sidekiq
The idea behind this was to avoid running
webpack-dev-server, which listens for changes and has an open socket for live refresh (unnecessary in this case).
Using git to pull the branch I'm working with and make sure the server is running. In order to expose it to the internet I use ngrok since they provide the SSL for me in this case (and I'm already a user of their product), so all I had to do is to make sure to tie all of this together and see it in action:
This is what it looks like on the outside:
And this is what it looks like on the inside:
- These things are powerful enough to run the entire stack in there with room to spare!
- I don't think they are as fast as x64 chips, but not by too much either
- The ARM ecosystem still has too many intricacies to make it viable for mainstream use, you'll be jumping through many hoops in order to get things to work
- The fact that you need to run on beta software & using outdated dependencies is a deal breaker, security & convenience wise
It was a fun experiment and actually useful for trying out a few things in development!