Hi! Im a student about to get a cs degree and new to a lot of concepts in production. I read about Erlang Elixir and Phoenix and decided to move all my degree projects to this environment.
I have various hots across providers and self hosted, my issue is I want to use the concepts in the BEAM machine to use the distribution aspect of the runtime so im having trouble getting the correct version in my hosts (rocky linux 10, freebsd 14.3) and now i am reading about using kerl or asdf.
Im seeking advice regarding those approaches (kerl/asdf) and anything that helps regarding elixir.
A release is a self-contained directory that consists of your application code, all of its dependencies, plus the whole Erlang Virtual Machine (VM) and runtime. Once a release is assembled, it can be packaged and deployed to a target as long as the target runs on the same operating system (OS) distribution and version as the machine that assembled the release.
When using different operating systems in production (such as Linux and FreeBSD) you will need to build a release for each platform. And as far as I know, you need to assemble the release on the same OS as you deploy to (i.e. “cross-builds” are not easily possible).
I use asdf to ensure that all developers are using the same version of Erlang and Elixir on a project, and in most cases it works quite well on Linux and MacOS. I expect that it would work on FreeBSD as well.
Do you have any specific question or issues with asdf?
If you are running on multiple host distributions something like Docker is going to be your best bet. Phoenix ships with a generator that will get you 90% there.
For distribution to work within docker the first step is to forward the port for epmd to your container; epmd is what a remote node will connect to first to figure out which network port your erlang/elixir node is bound to.
Now you will need to configure the port used by your node and forward it to your container as well - the release docs cover how to accomplish this.
Lastly you will need to configure the node name and cookie for the release. The node name can be configured in the same script that you use to set the node port and the cookie can be set using the environment variable RELEASE_COOKIE, see the environment section of the release docs for more info.
mix release is a good starting point. you start serving in bare metal granted you prepared the other stuffs like letsencrypt, systemd file for restarts, etc.
You can build release on your dev machine, so You don’t really need docker to test production environment for distribution.
At first I found configuring the cluster to be a little difficult, but once You set all the requested environment variables it starts to work properly. You need to know how to set RELEASE_NODE, RELEASE_NAME, RELEASE_COOKIE…
Two resources that you might want to look into down the line
I believe this is basically a quick guide to getting up and running on Fly.io, not sure how up to date it is, but it’s very quick and practical.
This one is much more involved and is overkill for what you’re doing now, but you might want to put it on your radar and come back to it if/when you start putting serious apps into production.
