[erlang-questions] Deploying forked Erlang releases?

[Theepan]

Hi Roger,

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.

·      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.

·      Then you create the release file (*.rel file)

·      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.

·      Crate your release package using the code target_system.erl, which
you can find in the link below.

·      Unpack it on any compatible platform.

·      Some times you will have to mark erl, and to_erl files as executable
in some platforms, from the unpacked directories.

·      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.

·      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.



Please follow the link below for details. It is pretty low level, but if
you do it once, it will be very easy.


http://www.erlang.org/doc/system_principles/create_target.html


Hope this helps.


Theepan

On Wed, Sep 9, 2015 at 7:52 PM, James Fish <james@REDACTED> wrote:

> 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.
>
> On 9 September 2015 at 15:10, Tristan Sloughter <t@REDACTED> wrote:
>
>> 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
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> 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/20150910/4550b30f/attachment.htm>