<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>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).<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>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).<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div id="sig19496053"><div class="signature">--<br></div>
<div class="signature">Tristan Sloughter<br></div>
<div class="signature">t@crashfast.com<br></div>
<div class="signature"> </div>
</div>
<div> </div>
<div> </div>
<div>On Wed, Sep 9, 2015, at 05:39 AM, Jesper Louis Andersen wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div> </div>
<div><div>On Wed, Sep 9, 2015 at 11:08 AM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net">roger@differentpla.net</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div style="overflow-x:hidden;overflow-y:hidden;"><div>3. Failing that, how are other people deploying Erlang? Do you just<br></div>
<div>
unpack a tarball into /?<br></div>
</div>
</blockquote></div>
</div>
<div><div>Releases.<br></div>
</div>
<div><div>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.<br></div>
</div>
<div>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.<br></div>
<div> </div>
<div><div>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.<br></div>
</div>
<div>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.<br></div>
<div><div> </div>
<div> </div>
<div>-- <br></div>
<div>J.<br></div>
</div>
</div>
<div><u>_______________________________________________</u><br></div>
<div>erlang-questions mailing list<br></div>
<div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br></div>
<div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div>
</blockquote><div> </div>
</body>
</html>