Erlang start application in production

问题:

When I'm testing my erlang application on localhost, I have a script that starts the server that looks like the following:

#!/bin/sh
PWD="$(pwd)"
NAME="$(basename $PWD)"
erl -pa "$PWD/ebin" deps/*/ebin -boot start_sasl \
    -name devnode@127.0.0.1 \
    -s reloader \
    -s $NAME \
    -setcookie some_random_cookie \
    +K true \
    +P 65536 

This prompts open the Erlang shell and from there I would type something like:

application:start(myapp)

This is fine for development purposes, but how do I deploy this in production? As of right now, the only way I can think of doing this is by starting a screen process and detaching from it. I don't think that should be the case. I am using rebar, if that helps at all.

回答1:

Sounds like you want to use a custom boot script. A boot script tells the erlang system what to start. In the script you're using, you're setting the boot script with:

-boot start_sasl

http://www.erlang.org/doc/system_principles/system_principles.html, look for the section "User-Defined Boot Scripts"

An easier option may be to convert your application to use rebar: https://github.com/basho/rebar. You would then be able to do the following:

./rebar compile generate

This will create a release for the application, allowing you to then:

./rel/<app_name>/bin/<app_name>

Same principles, just all wrapped up for easy use.

回答2:

Add the parameter -detached. The documentation summarizes this nicely:

Starts the Erlang runtime system detached from the system console. Useful for running daemons and backgrounds processes.

Once you do that, you can get your application to start with the -s parameter. Assuming $NAME = myapp, init will attempt to call myapp:start/0 (you can customize this if you want). That function should end with a call to application:start(myapp).

If you can get all of those puzzle pieces in place, you should have a working script.

回答3:

Well, you could try hooking it in to Apache (see here), or a simple solution that's not quite as hacky as screen sessions is to use nohup. If you're actually implementing this on a production server, and don't want to take the Apache route, you might consider an init script.