Hacker News new | ask | show | jobs
by fabian2k 2555 days ago
One part of releasing Elixir applications I never found a definite answer was how closely the build environment has to match the final environment where the release is deployed. The Erlang runtime is bundled with a release, and this part is platform-dependent as far as I understand.

If I'm writing an application that I'll only deploy myself I can of course match the environments exactly. But what about if I wanted to distribute an Elixir application to end users that might install it on all kinds of different operating systems and distributions? Do I have to build a release for OS/architecture combinations like Linux/64bit, Windows/32bit and similar? Or do I have to match each Linux distribution and windows version exactly? That would make it rather impractical to use Elixir to write software you give to other people, and don't deploy yourself.

Of course when I looked at this Distillery was the standard way to deploy, but it doesn't look like this part is any different with Elixir Releases.

3 comments

Currently releases require the OS and architecture to match. However, Erlang/OTP does support cross compilation, so at least a possibility is there, it needs to be further explored: http://erlang.org/doc/installation_guide/INSTALL-CROSS.html

The other concern is packages with NIFs (native code) and they would need to be changed if they don't support cross-compilation yet.

I believe Nerves, which is an Elixir framework for embedded, does a good amount of cross compilation too but they have a more controlled environment.

How does `mix release` handle NIFs currently? Same architecture is assumed?
Yes, basically it does not. It is up to the NIF packager to package a working way to handle that.
This sounds like a job for Docker to me. Build a container, deploy an image to Kubernetes. Someone else wants to use it, they can get it running wherever they want to run containers without worrying about the runtime environment other than just the container configuration.
We build it in Docker, but copy the release tarball out of the container and upload it directly to our servers.
It needs to be a matching libc. So a release that includes the Erlang runtime and is built on Debian (glibc) won't run on Alpine (musl).