4 ms·

Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual

Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.

nailer 11y ago
Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.
- rubiquity 11y ago
  There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deployment http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy... Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go. 0 - https://github.com/bitwalker/exrm https://github.com/bitwalker/exrm 1 - https://github.com/smpallen99/exrm-rpm https://github.com/smpallen99/exrm-rpm
- jake_morrison 11y ago
  We deploy using Erlang "releases", which bundle the Erlang vm along with your application and it's dependencies into a tarball with a script to run the application. You don't need to install Erlang on the target system, just unpack and run. We use "mix release" to build the tarball, scp to the server and unpack, then run using an upstart unit which runs "exec su -s /bin/sh -c 'exec "$0" "$@"' myuser -- /path/to/deploy/directory/bin/myapp foreground" It's pretty painless. We are automating with Fabric now, but will likely be switching to Ansible soon.
- simoncion 11y ago
  AFAIK, bytecode compiled on one Erlang system runs on any other. Bytecode is stored in .beam files, and -AIUI- .beam files are always forward compatible. However, I'm not sure if bytecode compiled with an Erlang version >=17.0 will run on earlier versions of Erlang if it makes use of maps. (Maps are a new type that was introduced in Erlang 17.0.) I should really test this.

nailer 11y ago

Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.

rubiquity 11y ago
There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deployment http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy... Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go. 0 - https://github.com/bitwalker/exrm https://github.com/bitwalker/exrm 1 - https://github.com/smpallen99/exrm-rpm https://github.com/smpallen99/exrm-rpm
jake_morrison 11y ago
We deploy using Erlang "releases", which bundle the Erlang vm along with your application and it's dependencies into a tarball with a script to run the application. You don't need to install Erlang on the target system, just unpack and run. We use "mix release" to build the tarball, scp to the server and unpack, then run using an upstart unit which runs "exec su -s /bin/sh -c 'exec "$0" "$@"' myuser -- /path/to/deploy/directory/bin/myapp foreground" It's pretty painless. We are automating with Fabric now, but will likely be switching to Ansible soon.
simoncion 11y ago
AFAIK, bytecode compiled on one Erlang system runs on any other. Bytecode is stored in .beam files, and -AIUI- .beam files are always forward compatible. However, I'm not sure if bytecode compiled with an Erlang version >=17.0 will run on earlier versions of Erlang if it makes use of maps. (Maps are a new type that was introduced in Erlang 17.0.) I should really test this.