5 ms·

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 rel

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.

josevalim 7y ago
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 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.
- pmarreck 7y ago
  How does `mix release` handle NIFs currently? Same architecture is assumed?
  - di4na 7y ago
    Yes, basically it does not. It is up to the NIF packager to package a working way to handle that.
SeanAppleby 7y ago
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.
- unvs 7y ago
  We build it in Docker, but copy the release tarball out of the container and upload it directly to our servers.
kungfooguru 7y ago
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).
walterstucco 7y ago
adding to what kungfooguru said, if your concern is just distributing the software, you don't need hot upgrades and you don't mind packaging the VM with it, you can compile to escript[1] and run the binary everywhere, just like you do with jars on the JVM (of course you need the BEAM installed on the system, while releases are self contained). [1] https://hexdocs.pm/mix/master/Mix.Tasks.Escript.Build.html https://hexdocs.pm/mix/master/Mix.Tasks.Escript.Build.html

josevalim 7y ago

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 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.

pmarreck 7y ago
How does `mix release` handle NIFs currently? Same architecture is assumed?
- di4na 7y ago
  Yes, basically it does not. It is up to the NIF packager to package a working way to handle that.

SeanAppleby 7y ago

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.

unvs 7y ago
We build it in Docker, but copy the release tarball out of the container and upload it directly to our servers.

kungfooguru 7y ago

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).

walterstucco 7y ago

adding to what kungfooguru said, if your concern is just distributing the software, you don't need hot upgrades and you don't mind packaging the VM with it, you can compile to escript[1] and run the binary everywhere, just like you do with jars on the JVM (of course you need the BEAM installed on the system, while releases are self contained). [1] https://hexdocs.pm/mix/master/Mix.Tasks.Escript.Build.html https://hexdocs.pm/mix/master/Mix.Tasks.Escript.Build.html