<div dir="ltr">
















<p><span style="font-family:Symbol">Hi Roger,</span></p><p>The above posts explain why an Erlang install is not required in the target server, here I explain how to create a release package. It is little messy, but if you get used to it, it will be very easy. You may want to create a script to do all the steps, but I am listing the steps, so that it may be helpful for some one in the future.</p><p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>In your build server, you will have to make
install Erlang (under /usr/local/lib/) and your custom applications (under
/usr/local/lib/erlang/lib/). I assume *X platforms.</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>Then you create the release file (*.rel file)</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>Create a configuration file (say sys.conf) for
all the custom application you have included. You take the environment
variables from your *.app file. It may contain some configurations for kernel
and other standard apps as well, depending on your requirements. It has some
conventions to follow, please look at the link provided below.</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>Crate your release package using the code
target_system.erl, which you can find in the link below.</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>Unpack it on any compatible platform.</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>Some times you will have to mark erl, and to_erl
files as executable in some platforms, from the unpacked directories.</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>Write your start/stop script. Here you will have
to give the path where you unpacked, configuration file (sys.conf), and other
parameters like node name, cookie (if you are running distributed systems),
whether you want to run the node in the background, whether Ctrl+C can kill the
node, whether you want to bind the schedulers to cores, mnesia directory (if
you are using Mnesia) and there are plenty more options. Please check
documentation for erl.</p>

<p><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">     
</span></span>You will have to carefully manage the Mnesia
database. Create it into your code, or launching an empty node from
your package using the a script and create it manually.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">Please follow the link below for details. It is pretty low
level, but if you do it once, it will be very easy.</p><p class="MsoNormal"><br></p><p class="MsoNormal"><a href="http://www.erlang.org/doc/system_principles/create_target.html">http://www.erlang.org/doc/system_principles/create_target.html</a><br></p><p class="MsoNormal"><br></p><p class="MsoNormal">Hope this helps.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Theepan</p>

</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 7:52 PM, James Fish <span dir="ltr"><<a href="mailto:james@fishcakez.com" target="_blank">james@fishcakez.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not directly an answer to your question but if the raw options are applicable for all listen sockets you can use the kernel config `inet_default_listen_options` to set default (raw) options for the underlying tcp socket.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 9 September 2015 at 15:10, Tristan Sloughter <span dir="ltr"><<a href="mailto:t@crashfast.com" target="_blank">t@crashfast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><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><div>--<br></div>
<div>Tristan Sloughter<br></div>
<div><a href="mailto:t@crashfast.com" target="_blank">t@crashfast.com</a><br></div>
<div> </div>
</div><div><div>
<div> </div>
<div> </div>
<div>On Wed, Sep 9, 2015, at 05:39 AM, Jesper Louis Andersen wrote:<br></div>
</div></div><blockquote type="cite"><div><div><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" target="_blank">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></div><span><div><u>_______________________________________________</u><br></div>
<div>erlang-questions mailing list<br></div>
<div><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br></div>
<div><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div>
</span></blockquote><div> </div>
</div>

<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>