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 an release resource file,
or in short .rel
file:
{release, {Name,Vsn}, {erts, EVsn}, [{Application1, AppVsn1}, ... {ApplicationN, AppVsnN}]}.
The file must be named Rel.rel
, where Rel
is a
unique name.
Name
and Vsn
(strings) are the name and version of
the release.
Evsn
(string) is the ERTS version the release is intended
for.
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.
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 release resource 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", "1"}, {erts, "5.2.3.6"}, [{kernel, "2.8.1.3"}, {stdlib, "1.11.4.3"}, {sasl, "1.9.4"}, {ch_app, "1"}] }.
There are tools in the module systools
available to build
and check releases. The functions read the release resource file
and the application resource files and performs syntax and
dependency checks. The function systools:make_script/1,2
is
used to generate a boot script.
1> systools:make_script("ch_rel-1", [local]). ok
This creates a boot script ch_rel-1.script
.
"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.
A binary version ch_rel-1.boot
of the script must be
generated:
2> systools:script2boot("ch_rel-1"). ok
When starting Erlang/OTP using the boot script, all applications
from the .rel
file are automatically started:
% erl -boot ch_rel-1 Erlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0] Eshell V5.2.3.6 (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:script2boot("ch_rel-1"). ok 3> 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 release resource file.
% tar tf ch_rel-1.tar lib/kernel-2.8.1.3/ebin/kernel.app lib/kernel-2.8.1.3/ebin/application.beam ... lib/stdlib-1.11.4.3/ebin/stdlib.app lib/stdlib-1.11.4.3/ebin/beam_lib.beam ... lib/sasl-1.9.4/ebin/sasl.app lib/sasl-1.9.4/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/1/start.boot releases/ch_rel-1.rel
Options can be set to make the release package include source code and the ERTS binary as well.
The release package should be unpacked and installed using the release handler. See System Principles for how this is done when installing a target system and Release Handling for how to do it in an existing system.
Directory structure for the code installed by the release handler from a release package:
$ROOTDIR/lib/App1-AVsn1/ebin /priv /App2-AVsn2/ebin /priv ... /AppN-AVsnN/ebin /priv /erts-EVsn/bin /releases/Vsn /bin
lib
releases/Vsn
directory. Vsn
is the release
version found in the release resource file.
erts-EVsn/bin
releases/Vsn
.rel
file.
bin
erl
.
Applications are not required to be located under the
$ROOTDIR/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 $ROOTDIR
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 $ROOTDIR
directory contains the following:
$ROOTDIR/... /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 ROOTDIR
per type of machine. For each
type, some of the directories specified for the ROOTDIR
directory should be included:
$ROOTDIR/... /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 $ROOTDIR/clients/Type1
.