[erlang-questions] Deploying forked Erlang releases?

[Tristan Sloughter]

Right, no need to install Erlang itself on a server. Better to build
your release into a tarball (including erts makes it a target system)
which you can then unpack and run "anywhere" (since it contains erts it
has to be the same platform).

relx (which rebar3 uses and can be used standalone) generates a useful
start script (set {extended_start_script, true} in the config of your
project) with options for starting, stopping, getting a remote console,
upgrading the release, and more.

And unless you need special options you can have the tarball built
even somewhere like travis. We have travis-ci build the tarball when
a tag is pushed in github and upload it to s3. Then our deployment
tools can fetch a version from s3, unpack it and start (or if it is
doing an upgrade, it downloads the tarball and runs the start scripts
'upgrade' command).

But since you need a custom build that isn't an option :), but if you
have some other CI server the same can be done and you only have to
install your custom Erlang build on it and dev machines instead of
the servers.

--
Tristan Sloughter
t@REDACTED
 
 
 
On Wed, Sep 9, 2015, at 05:39 AM, Jesper Louis Andersen wrote:
>  
> On Wed, Sep 9, 2015 at 11:08 AM, Roger Lipscombe <roger@REDACTED> wrote:
>> 3. Failing that, how are other people deploying Erlang? Do you just
>> 
unpack a tarball into /?
> Releases.
> A release packs an ERTS together with your code, so it is self-contained. You then don't have to deploy an Erlang package next to your code. Whatever ERTS the build-host uses is the one that is packaged into the release. This solves the problem of having a locally patched Erlang.
> For building Erlang releases, anything now goes. We use kerl, but we don't require special patches on top of Erlang, just some compiler flags (--disable-hipe, --enable-dirty-schedulers,--with-dynamic-trace=dtrace). However, this is easily adaptable to a patched world with the (experimental) kerl git option.
>  
> We often simply deploy these as tarballs which we unpack somewhere (/opt/foo or /usr/local/foo depending on OS type). Then we install some start-script for them and we are good to go.
> I spent much time trying to get packaging right in $OS, but recently, I've had more success with the above low-level method. In a world where it is easy to "roll a new machine", you can just use that machine as a starting point. You don't have to worry too much about being able to remove software from the system again, which is one of the primary reasons for the existence of package managers.
>  
>  
> -- 
> J.
> _________________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150909/b63572d1/attachment.htm>