[Erlang Systems]

10 Releases

This chapter should be read in conjuction with rel(4), systools(3) and script(4).

10.1 Release Concept

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.

10.2 Release Resource File

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"}]
}.

10.3 Generating Boot Scripts

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

10.4 Creating a Release Package

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.

10.5 Directory Structure

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
Application directories.
The boot script and relup files should be located in the releases/Vsn directory. Vsn is the release version found in the release resource file.
erts-EVsn/bin
Erlang runtime system executables.
releases/Vsn
.rel file.
bin
Top level Erlang executable program 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.

10.5.1 Disk-Less and/or Read-Only Clients

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.

Copyright © 1991-2003 Ericsson Utvecklings AB