View Source Releases
This section is to be read with the rel(4), systools, and script(4)
manual pages in SASL.
Release Concept
When you have written one or more applications, you might want to create a complete system with these applications and a subset of the Erlang/OTP applications. This is called a release.
To do this, create a release resource file that defines which applications are included in the release.
The release resource file is used to generate boot scripts and release packages. A system that is transferred 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.
Release Resource File
To define a release, create a release resource file, or in short a .rel
file. In the file, 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}]}.Name, Vsn, EVsn, and AppVsn are strings.
The file must be named Rel.rel, where Rel is a unique name.
Each Application (atom) and AppVsn is the name and version of an application
included in the release. The minimal release based on Erlang/OTP consists of the
Kernel and STDLIB applications, so these applications must be included in the
list.
If the release is to be upgraded, it must also include the SASL application.
Example: A release of ch_app from Applications 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, as these
applications are required by ch_app. The file is called ch_rel-1.rel:
{release,
{"ch_rel", "A"},
{erts, "5.3"},
[{kernel, "2.9"},
{stdlib, "1.12"},
{sasl, "1.10"},
{ch_app, "1"}]
}.Generating Boot Scripts
systools in the SASL application includes tools to build and check releases.
The functions read the rel and .app files and perform syntax and dependency
checks. The systools:make_script/1,2 function is used to generate a boot
script (see System Principles):
1> systools:make_script("ch_rel-1", [local]).
okThis creates a boot script, both the readable version, ch_rel-1.script, and
the binary version, ch_rel-1.boot, used by the runtime system.
"ch_rel-1"is the name of the.relfile, minus the extension.localis an option that means that the directories where the applications are found are used in the boot script, instead of$ROOT/lib($ROOTis 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@nohostCreating a Release Package
The systools:make_tar/1,2 function 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").
okThe release package by default contains:
- The
.appfiles - The
.relfile - The object code for all applications, structured according to the application directory structure
- The binary boot script renamed to
start.boot
% 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/A/ch_rel-1.rel
releases/ch_rel-1.relA 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. You do not know where the release package will be
installed, so no hard-coded absolute paths are allowed.
The release resource file mysystem.rel is duplicated in the tar file.
Originally, this file was only stored in the releases directory to make it
possible for the release_handler to extract this file separately. After
unpacking the tar file, release_handler would automatically copy the file to
releases/FIRST. However, sometimes the tar file is unpacked without involving
the release_handler (for example, when unpacking the first target system) and
the file is therefore now instead duplicated in the tar file so no manual
copying is necessary.
If a relup file and/or a system configuration file called sys.config, or a
sys.config.src, is found, these files are also included in the release
package. See Release Handling.
Options can be set to make the release package include source code and the ERTS binary as well.
For information on how to install the first target system, using a release package, see System Principles. For information on how to install a new release package in an existing system, see Release Handling.
Directory Structure
The directory structure for the code installed by the release handler from a release package is as follows:
$ROOT/lib/App1-AVsn1/ebin
/priv
/App2-AVsn2/ebin
/priv
...
/AppN-AVsnN/ebin
/priv
/erts-EVsn/bin
/releases/Vsn
/binlib- Application directorieserts-EVsn/bin- Erlang runtime system executablesreleases/Vsn-.relfile and boot scriptstart.boot; if present in the release package,relupand/orsys.configorsys.config.srcbin- Top-level Erlang runtime system executables
Applications are not required to be located under directory $ROOT/lib. Several
installation directories, which contain different parts of a system, can thus
exist. For example, the previous example can 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$SECOND_ROOT and $THIRD_ROOT are introduced as variables in the call to
the systools:make_script/2 function.
Disk-Less and/or Read-Only Clients
If a complete system consists of disk-less and/or read-only client nodes, a
clients directory is to be added to the $ROOT directory. A read-only node is
a node with a read-only file system.
The clients directory is to have one subdirectory per supported client node.
The name of each client directory is to be the name of the corresponding client
node. As a minimum, each client directory is to contain the bin and releases
subdirectories. These directories are used to store information about installed
releases and to appoint the current release to the client. The $ROOT directory
thus contains the following:
$ROOT/...
/clients/ClientName1/bin
/releases/Vsn
/ClientName2/bin
/releases/Vsn
...
/ClientNameN/bin
/releases/VsnThis structure is to 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 can be divided into one
subdirectory per type of Erlang machine. Alternatively, one $ROOT can be set
up per type of machine. For each type, some of the directories specified for the
$ROOT directory are to 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.