10. Release

This chapter should workREL (4),Systools (3)AndScript (4).

Release Concept

When one or more applications have been written, we may want to create a complete system composed of these applications and a subset of Erlang/OTP applications.

To achieve this goal, we create a release resource file that defines the applications to be included in the release.

The published resource file is used to generateStart scriptAndRelease package. The system sent and installed on another site is calledTarget System. If you use a release package to create a target system, it is described in system principles.

Publish resource files

To define a release, you must first createPublish resource files, Abbreviation.relFile, here we specify the name and version of the release, which ERTs version it is based on, and which applications it consists:

{release, {Name,Vsn}, {erts, EVsn}, [{Application1, AppVsn1},   ...  {ApplicationN, AppVsnN}]}.

The file must be calledRel.rel, WhereRelIs a unique name.

Name,VsnAndEvsnAll are strings.

EachApplication(Atomic) andAppVsn(String) is the name and version of the application contained in the release. Note that the minimum release based on Erlang/OTP is implemented by the applicationkernelAndstdlibTherefore, these two applications must be included in the list.

For example, we want to createApplicationChapter 1ch_app. This application contains the following.appFile:

{application, ch_app, [{description, "Channel allocator"},  {vsn, "1"},  {modules, [ch_app, ch_sup, ch3]},  {registered, [ch3]},  {applications, [kernel, stdlib, sasl]},  {mod, {ch_app,[]}} ]}.

.relThe file must also containkernel,stdlibAndsaslBecause these applications arech_appRequired. We call this filech_rel-1.rel:

{release, {"ch_rel", "A"}, {erts, "5.3"}, [{kernel, "2.9"},  {stdlib, "1.12"},  {sasl, "1.10"},  {ch_app, "1"}]}.

Generate Startup Script

In the SASL ModulesystoolsThere are many tools that can be used to build and test the release. Function reading.relAnd.appFile and perform the syntax and dependency check. Functionsystools:make_script/1,2Used to generate a STARTUP script (see system principles ).

1> systools:make_script("ch_rel-1", [local]).ok

This creates a STARTUP script, including a readable version.ch_rel-1.scriptBinary version used by the runtime systemch_re-1.boot. "ch_rel-1"Yes.relRemove the name of the file extension.localIs an option that indicates the directory of the application used in the startup script.$ROOT/lib. ($ROOTIs the root directory of the installed Release) is very useful for the startup script generated by the local test.

When you use the startup script to start Erlang/OTP,.relAll applications in the file will be automatically loaded and started:

% erl -boot ch_rel-1Erlang (BEAM) emulator version 5.3Eshell 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: [email protected]...=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===         application: ch_app          started_at: [email protected]

Create a release package

Functionsystools:make_tar/1,2Take.relFile as the input, and create a compressed tar package that contains the specified application, that is,Release package(Release package ).

1> systools:make_script("ch_rel-1").ok2> systools:make_tar("ch_rel-1").ok

The default release package contains.appFile and target code, and accordingApplication directory structureCreate a structure and rename the binary STARTUP scriptstart.boot, Including.relFile.

% tar tf ch_rel-1.tarlib/kernel-2.9/ebin/kernel.applib/kernel-2.9/ebin/application.beam...lib/stdlib-1.12/ebin/stdlib.applib/stdlib-1.12/ebin/beam_lib.beam...lib/sasl-1.10/ebin/sasl.applib/sasl-1.10/ebin/sasl.beam...lib/ch_app-1/ebin/ch_app.applib/ch_app-1/ebin/ch_app.beamlib/ch_app-1/ebin/ch_sup.beamlib/ch_app-1/ebin/ch3.beamreleases/A/start.bootreleases/ch_rel-1.rel

Note that the new startup script is not set before the release package is created.local. In the release package, all application directories are placedlib. At the same time, we do not know where the release package will be installed, so we do not want to hard encode any absolute path in the startup script.

If onerelupFile and/orsys.configSystem configuration files, which are also included in the release package. SeeRelease Processing:

You can also set parameters to include the code and ERTs binary files in the release package.

For more information about how to use the release package to install the first target system, see system principles. If a new release package is installed on an existing system, seeRelease Processing.

Directory structure

The directory structure of the code for the total installation of the release processor from the release package:

$ROOT/lib/App1-AVsn1/ebin                  /priv       /App2-AVsn2/ebin                  /priv       ...       /AppN-AVsnN/ebin                  /priv   /erts-EVsn/bin   /releases/Vsn   /bin

lib

Application directory.

erts-EVsn/bin

The executable file of the system when Erlang is running.

releases/Vsn

.relFile and startup script start.boot. And relup, sys.config, If it exists in the release package.

bin

The system executable file when the top-level Erlang is running.

Applications do not have to be placed$ROOT/libDirectory. In this way, some installation directories can exist and contain different parts of a system. For example, the preceding example can be expanded 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

Where$SECOND_ROOTAnd$THIRD_ROOTYes as a callsystools:make_script/2The variable introduced in the function.

Diskless and read-only client

If a complete system contains some diskless and read-only client nodes$ROOTAddclientsDirectory. A read-only node means that the file system of a node is read-only.

clientsThe Directory should also have a subdirectory for each supported client node. The name of each client directory must be the name of the corresponding client node. Each Client Directory should also containbinAndreleasesSubdirectory. These directories are used to store information about the installation release and assign the current release to the client. As described above,$ROOTThe Directory should contain the following content:

$ROOT/...    /clients/ClientName1/bin                        /releases/Vsn            /ClientName2/bin                        /releases/Vsn            ...            /ClientNameN/bin                        /releases/Vsn

If all clients run on the same type of Erlang machine, this structure should be used. If some clients run different types of Erlang machines, that is, they run on different operating systemsclientsDirectories can be divided into one sub-directory for each Erlang machine. Alternatively, you can set$ROOT. For each type, it should also contain$ROOTSpecified directories:

$ROOT/...    /clients/Type1/lib                  /erts-EVsn                  /bin                  /ClientName1/bin                              /releases/Vsn                  /ClientName2/bin                              /releases/Vsn                  ...                  /ClientNameN/bin                              /releases/Vsn            ...            /TypeN/lib                  /erts-EVsn                  /bin                  ...

For this structure,Type1The root directory of the client is$ROOT/clients/Type1.

10. Release