Best practices for distributing an application over erlang?

[Gregory Haskins]

Hi All,

I have been struggling trying to wrap my head around what might be the
best-practice for distributing a clustered erlang-application to a
plurality of erlang nodes, and keeping the cluster up to date from a
central location.

Ideally, the subordinate erlang nodes that have just-enough logic to
connect to one another (e.g. cookies, ssl-keys, gossip-controller
addresses, etc are pre-distributed) but otherwise no specific
personality is known apriori.  I can then implement some kind of central
service to remotely load/run a specific application (and any of its
dependencies).  IOW: This is really about bootstrap for the time being
(e.g. Hot update is nice, but not a short term requirement at the
moment).  The right conceptual vehicle for the payload would be a
standard erlang-release.

So I have given this a lot of thought and read a ton of the books/doc on
the various options here.  For instance, I have seen Joe Armstrong's
examples of sending a lambda down as payload in a message, using
dist_ac, boot-server, release_handler, etc.  Every solution seems to
present its own set of problems/limitations, so I am unclear as to what
might be my best option here.

For instance, sending functions as payload only seems to work as long as
that function only invokes modules that already loaded/available on the
remote node.  I can, of course, ensure that all required modules are
loaded on the remote node using things like code:load_binary(), but this
would mean I would need to a) figure out what modules are needed as part
of the release I want to distribute, and b) manually load each and every
module to the remote node, right?

As far as dist_ac, this seems to be more geared towards creating
active/standby replicas of an app, rather than a process-peer model, so
that's out.

boot-server is getting warmer, though I really want my grid to use
SSL-mutualauth + cookies, and I am not sure if the erl_prim_loader can
work over SSL inets.

release_handler is getting warmer, though I still need to address the
bootstrap problem (either pre-load the initial release or use the
erl_prim_loader, as above).  The other problem here is its focus is
really on hot-update, and at this juncture I really only care about
remote-update (e.g. cold restart is probably ok for now).

One solution I thought of is a play on the boot-server model, where I
can have one erlang application that connects in whatever ssl/cookie
protocol I want, contacts the service, downloads the release.tar.gz, and
then fires up a new beam instance with the release...hot updates, if
desired, could just use standard release-handler calls direct to the
subordinate vm.  The problem with this solution is then I get into "well
how do I keep my loader-app up to date?" and my head explodes in a
circular reference ;).

Long story short(er):  I suspect I am just making all of this harder
than it needs to be, and there must be a ton of you who are just doing
similar operations all the time.  Any help/pointers/guidance/suggestions
appreciated.

Kind Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110215/45be5391/attachment.bin>