[erlang-questions] Deploying forked Erlang releases?

James Fish james@REDACTED
Wed Sep 9 16:22:42 CEST 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150909/000b8447/attachment.htm>


More information about the erlang-questions mailing list