Nicd

Deploying a release from an ARM laptop

I recently got an ARM laptop to replace my old amd64 one. This poses a problem for me. I run my production service on an amd64 VPS (Hetzner) that runs Ubuntu Server.

Thus far I’ve used a Vagrant box with Ubuntu to build a release in, and then uploaded that release to my production server, unpacked it, and restarted (it’s quite manual, yes, but I don’t release often). Now, of course, due to NIFs such as Comeonin and AppSignal, I cannot build on ARM.

How have you typically handled this? I found some earlier threads suggesting the use of Docker or building the release on GitHub (I use GitLab though):

Is this still the way to go? I have tried Burrito earlier, but I could not get it to build the release correctly (problem with NIFs).

I know nowadays I could run an ARM VM with amd64 binaries inside using Rosetta 2, but I don’t know how big of a hassle it would be.

One thought was GitLab CI, I guess I could use that to build a release out of every push to some branch? Could I get it to match the Ubuntu environment closely enough so that it would work? Though, I’m on a free account so I don’t know how much processing it allows me to do.

21 comments

#arm

25 2198 21

2023-06-13 11:08:14 UTC

Marked As Solved

Nicd

Thanks everyone for the answers, I hope they are also useful for any future readers that might find this thread. I ended up building the release in GitLab CI which was surprisingly painless. I haven’t tested deploying the artifact yet, though, but it looks sensible enough when extracted.

Post #14

Also Liked

l3nz

We use Hetzner too. With their CLI tool, you can deploy a new VM, install OTP, rsync your program, release, download, shutdown and you’d incur in 15 minutes of usage total… so just a few € cents.

Post #6

jbriggs

I build releases for ARM systems on an x86 build server.

I take the files for the ARM system’s ERTS, place them on the build server and then reference them in the release I am building.

Here is a snippet from the mix.exs, “releases” section:

  releases: [                                                                                                               
    sra_rps: [
      overwrite: true,
      include_executables_for: [:unix],

      # Keep the docs
      strip_beams: [keep: ["Docs", "Dbgi"]],

      # Path to the ERTS copied from ~/.asdf/installs/erlang/24.2.1
      include_erts: "/usr/local/share/erlang_rps/erts-12.2.1",
      ...

The only provisio is that building any NIFs or port programs becomes much more complicated. The only port programs I have are very stable, never needing changes, so I include compiled versions as binaries in priv.

Post #17

c4710n

In my case, I’m using:

an x86_64 linux emulator
a docker service running on above emulator

When building x86_64 docker image, I use above docker service.

On my MBP 2015, the build can be done in 4 min. But in the emulator on MBP 2021, the building process can slow 4 times, I think. (I didn’t measure it precisely. All I know is that my tea will be cold after the build. )

Post #11

LostKobrakai

That’s exactly the reason why I push all my builds to CI from day 1. Usually the free plans are enough for my private stuff and for non private stuff a few bucks a month should be doable. No need to worry about where and how I do my edits, could even be the built in editor of the service hosting the repo for what it’s worth. I totally see that being a bit more work upfront, but it’s documented in code and rather flexible.

Post #12

Nicd

Oh, and here’s the configuration I ended up with (permalinked to the current version, so maybe check if it has changed if you come from the future): .gitlab-ci.yml · e037b3c8245f2db487a13539062de726749b6156 · CodeStats / code-stats · GitLab

Let me know if you think I could do something better!

Post #15