User's Guide
PDF
Top

OTP Design Principles
User's Guide
Version 5.9.2

Expand All
Contract All

Chapters

- Overview
  - Top of chapter
  - Supervision Trees
  - Behaviours
  - Applications
  - Releases
  - Release Handling
- Gen_Server Behaviour
  - Top of chapter
  - Client-Server Principles
  - Example
  - Starting a Gen_Server
  - Synchronous Requests - Call
  - Asynchronous Requests - Cast
  - Stopping
  - Handling Other Messages
- Gen_Fsm Behaviour
  - Top of chapter
  - Finite State Machines
  - Example
  - Starting a Gen_Fsm
  - Notifying About Events
  - Timeouts
  - All State Events
  - Stopping
  - Handling Other Messages
- Gen_Event Behaviour
  - Top of chapter
  - Event Handling Principles
  - Example
  - Starting an Event Manager
  - Adding an Event Handler
  - Notifying About Events
  - Deleting an Event Handler
  - Stopping
  - Handling Other Messages
- Supervisor Behaviour
  - Top of chapter
  - Supervision Principles
  - Example
  - Restart Strategy
  - Maximum Restart Frequency
  - Child Specification
  - Starting a Supervisor
  - Adding a Child Process
  - Stopping a Child Process
  - Simple-One-For-One Supervisors
  - Stopping
- Sys and Proc_Lib
  - Top of chapter
  - Simple Debugging
  - Special Processes
  - User-Defined Behaviours
- Applications
  - Top of chapter
  - Application Concept
  - Application Callback Module
  - Application Resource File
  - Directory Structure
  - Application Controller
  - Loading and Unloading Applications
  - Starting and Stopping Applications
  - Configuring an Application
  - Application Start Types
- Included Applications
  - Top of chapter
  - Definition
  - Specifying Included Applications
  - Synchronizing Processes During Startup
- Distributed Applications
  - Top of chapter
  - Definition
  - Specifying Distributed Applications
  - Starting and Stopping Distributed Applications
  - Failover
  - Takeover
- Releases
  - Top of chapter
  - Release Concept
  - Release Resource File
  - Generating Boot Scripts
  - Creating a Release Package
  - Directory Structure
- Release Handling
  - Top of chapter
  - Release Handling Principles
  - Requirements
  - Distributed Systems
  - Release Handling Instructions
  - Application Upgrade File
  - Release Upgrade File
  - Installing a Release
  - Updating Application Specifications
- Appup Cookbook
  - Top of chapter
  - Changing a Functional Module
  - Changing a Residence Module
  - Changing a Callback Module
  - Changing Internal State
  - Module Dependencies
  - Changing Code For a Special Process
  - Changing a Supervisor
  - Adding or Deleting a Module
  - Starting or Terminating a Process
  - Adding or Removing an Application
  - Restarting an Application
  - Changing an Application Specification
  - Changing Application Configuration
  - Changing Included Applications
  - Changing Non-Erlang Code
  - Emulator Restart and Upgrade
  - Emulator Upgrade from pre OTP R15

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

### 10.3 Generating Boot Scripts

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

### 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: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/A/ch_rel-1.rel
    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.

The release resource file mysystem.rel is duplicated in the tar file. Originally, this file was only stored in the releases directory in order 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 (e.g. when unpacking the first target system) and therefore the file is 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 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.

### 10.5 Directory Structure

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
  Application directories.
erts-EVsn/bin
  Erlang runtime system executables.
releases/Vsn
  .rel file and boot script start.boot.
  If present in the release package,
  relup and/or sys.config.
bin
  Top level Erlang runtime system executables.

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.

#### 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 $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.