What are best practices for making Erlang releases?

Question

I\'ve been checking out Faxien+Sinan and Rebar, and the basic philosophy of Erlang OTP seems to be, install applications and releases on a single Erlang image instance. What ar

Answer 1

IMHO this can't be answered in a few sentences. You should have to read some parts of the included documentation, especially "Erlang/OTP System Documentation" (otp-system-documentation-X.Y.Z.pdf, with X.Y.Z being the version number), or have a look at the book "Erlang and OTP in Action" because throughout this book there is "one" example of a "service" with different "parts" from the first steps, using Erlang/OTP concepts and finally building a "release".

IMHO this is currently the best book around, because it not only introduces Erlang, but also shows what OTP is and how OTP is used for a project. And it is not just a collection of loose samples, but everything is build around a single project.

Answer 2

I'll describe the approach that currently works for me for regular (often daily) releases to a small number of instances on EC2:

1. I set up my project with rebar and check it into github.
2. All of my dependencies are listed in my rebar.config file (they too are on github).
3. My Makefile looks similar to what I described here.
4. My EC2 image only has a regular build of erlang and no other libs installed by default.
5. To create a new node, I spin up an instance, clone my git repository, and run make. This will fetch my dependencies and build everything.
6. To update my code I do a git pull and a rebar update-deps. Depending on what changed I may restart the node or, quite often, I'll attach to the running node and reload the updated modules. It helps to have start and attach scripts as part of your project.

It may be helpful to look at how a project like webmachine is packaged.

I don't know much about the standard OTP release management system, other than it looks like a lot of work. Because this seems counter to rapid deployment, I never gave it a serious try - though I'm certain it makes sense for other projects.