![[Ericsson AB]](min_head.gif)
This chapter should be read in conjuction with rel(4),
systools(3) and script(4).
When we have written one or more applications, we might want to create a complete system consisting of these applications and a subset of the Erlang/OTP applications. This is called a release.
To do this, we create a release resource file which defines which applications are included in the release.
The release resource file is used to generate boot scripts and release packages. A system which is transfered to and installed at another site is called a target system. How to use a release package to create a target system is described in System Principles.
To define a release, we create a release resource file,
or in short .rel file, where we specify the name and
version of the release, which ERTS version it is based on, and
which applications it consists of:
{release, {Name,Vsn}, {erts, EVsn},
[{Application1, AppVsn1},
...
{ApplicationN, AppVsnN}]}.
The file must be named Rel.rel, where Rel is a
unique name.
Name, Vsn and Evsn are strings.
Each Application (atom) and AppVsn (string) is
the name and version of an application included in the release.
Note the the minimal release based on Erlang/OTP consists of
the kernel and stdlib applications, so these
applications must be included in the list.
Example: We want to make a release of ch_app from
the Applications
chapter. It has the following .app file:
{application, ch_app,
[{description, "Channel allocator"},
{vsn, "1"},
{modules, [ch_app, ch_sup, ch3]},
{registered, [ch3]},
{applications, [kernel, stdlib, sasl]},
{mod, {ch_app,[]}}
]}.
The .rel file must also contain kernel,
stdlib and sasl, since these applications are
required by ch_app. We call the file ch_rel-1.rel:
{release,
{"ch_rel", "A"},
{erts, "5.3"},
[{kernel, "2.9"},
{stdlib, "1.12"},
{sasl, "1.10"},
{ch_app, "1"}]
}.
There are tools in the SASL module systools available to
build and check releases. The functions read the .rel and
.app files and performs syntax and dependency checks.
The function systools:make_script/1,2 is used to generate
a boot script (see System Principles).
1> systools:make_script("ch_rel-1", [local]).
ok
This creates a boot script, both the readable version
ch_rel-1.script and the binary version used by the runtime
system, ch_rel-1.boot. "ch_rel-1" is the name of
the .rel file, minus the extension. local is an
option that means that the directories where the applications are
found are used in the boot script, instead of $ROOT/lib.
($ROOT is the root directory of the installed release.)
This is a useful way to test a generated boot script locally.
When starting Erlang/OTP using the boot script, all applications
from the .rel file are automatically loaded and started:
% erl -boot ch_rel-1
Erlang (BEAM) emulator version 5.3
Eshell V5.3 (abort with ^G)
1>
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
supervisor: {local,sasl_safe_sup}
started: [{pid,<0.33.0>},
{name,alarm_handler},
{mfa,{alarm_handler,start_link,[]}},
{restart_type,permanent},
{shutdown,2000},
{child_type,worker}]
...
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
application: sasl
started_at: nonode@nohost
...
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
application: ch_app
started_at: nonode@nohost
There is a function systools:make_tar/1,2 which takes
a .rel file as input and creates a zipped tar-file with
the code for the specified applications, a release
package.
1> systools:make_script("ch_rel-1").
ok
2> systools:make_tar("ch_rel-1").
ok
The release package by default contains the .app files and
object code for all applications, structured according to
the application directory
structure, the binary boot script renamed to
start.boot, and the .rel file.
% tar tf ch_rel-1.tar
lib/kernel-2.9/ebin/kernel.app
lib/kernel-2.9/ebin/application.beam
...
lib/stdlib-1.12/ebin/stdlib.app
lib/stdlib-1.12/ebin/beam_lib.beam
...
lib/sasl-1.10/ebin/sasl.app
lib/sasl-1.10/ebin/sasl.beam
...
lib/ch_app-1/ebin/ch_app.app
lib/ch_app-1/ebin/ch_app.beam
lib/ch_app-1/ebin/ch_sup.beam
lib/ch_app-1/ebin/ch3.beam
releases/A/start.boot
releases/ch_rel-1.rel
Note that a new boot script was generated, without
the local option set, before the release package was made.
In the release package, all application directories are placed
under lib. Also, we do not know where the release package
will be installed, so we do not want any hardcoded absolute paths
in the boot script here.
If a relup file and/or a system configuration file called
sys.config is found, these files are included in
the release package as well. See
Release Handling.
Options can be set to make the release package include source code and the ERTS binary as well.
Refer to System Principles for how to install the first target system, using a release package, and to Release Handling for how to install a new release package in an existing system.
Directory structure for the code installed by the release handler from a release package:
$ROOT/lib/App1-AVsn1/ebin
/priv
/App2-AVsn2/ebin
/priv
...
/AppN-AVsnN/ebin
/priv
/erts-EVsn/bin
/releases/Vsn
/bin
lib
erts-EVsn/bin
releases/Vsn
.rel file and boot script start.boot.relup and/or sys.config.
bin
Applications are not required to be located under the
$ROOT/lib directory. Accordingly, several installation
directories may exist which contain different parts of a
system. For example, the previous example could be extended as
follows:
$SECOND_ROOT/.../SApp1-SAVsn1/ebin
/priv
/SApp2-SAVsn2/ebin
/priv
...
/SAppN-SAVsnN/ebin
/priv
$THIRD_ROOT/TApp1-TAVsn1/ebin
/priv
/TApp2-TAVsn2/ebin
/priv
...
/TAppN-TAVsnN/ebin
/priv
The $SECOND_ROOT and $THIRD_ROOT are introduced as
variables in the call to the systools:make_script/2
function.
If a complete system consists of some disk-less and/or
read-only client nodes, a clients directory should be
added to the $ROOT directory. By a read-only node we
mean a node with a read-only file system.
The clients directory should have one sub-directory
per supported client node. The name of each client directory
should be the name of the corresponding client node. As a
minimum, each client directory should contain the bin and
releases sub-directories. These directories are used to
store information about installed releases and to appoint the
current release to the client. Accordingly, the $ROOT
directory contains the following:
$ROOT/...
/clients/ClientName1/bin
/releases/Vsn
/ClientName2/bin
/releases/Vsn
...
/ClientNameN/bin
/releases/Vsn
This structure should be used if all clients are running
the same type of Erlang machine. If there are clients running
different types of Erlang machines, or on different operating
systems, the clients directory could be divided into one
sub-directory per type of Erlang machine. Alternatively, you
can set up one $ROOT per type of machine. For each
type, some of the directories specified for the $ROOT
directory should be included:
$ROOT/...
/clients/Type1/lib
/erts-EVsn
/bin
/ClientName1/bin
/releases/Vsn
/ClientName2/bin
/releases/Vsn
...
/ClientNameN/bin
/releases/Vsn
...
/TypeN/lib
/erts-EVsn
/bin
...
With this structure, the root directory for clients of
Type1 is $ROOT/clients/Type1.