From 42a0387e886ddbf60b0e2cb977758e2ca74954ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Thu, 12 Mar 2015 15:35:13 +0100 Subject: Update Design Principles MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Language cleaned up by the technical writers xsipewe and tmanevik from Combitech. Proofreading and corrections by Björn Gustavsson. --- system/doc/design_principles/release_structure.xml | 190 +++++++++++---------- 1 file changed, 98 insertions(+), 92 deletions(-) (limited to 'system/doc/design_principles/release_structure.xml') diff --git a/system/doc/design_principles/release_structure.xml b/system/doc/design_principles/release_structure.xml index cec33f42e3..aa04f5e6a3 100644 --- a/system/doc/design_principles/release_structure.xml +++ b/system/doc/design_principles/release_structure.xml @@ -28,21 +28,23 @@ release_structure.xml -

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

+ +

This section is to be read with the rel(4), systools(3), + and script(4) manual pages in SASL.

Release Concept -

When we have written one or more applications, we might want to - create a complete system consisting of these applications and a +

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, we create a release resource file which defines which applications - are included in the 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 - which is transfered to and installed at another site is called a + 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.

@@ -50,29 +52,30 @@
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:

+

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.

-

Name, Vsn and EVsn are strings.

-

Each Application (atom) and AppVsn (string) is +

Each Application (atom) and AppVsn 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 + 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.

+ the SASL application.

-

Example: We want to make a release of ch_app from - the Applications - chapter. It has the following .app file:

+

Example: A release of ch_app from + Applications + has the following .app file:

{application, ch_app, [{description, "Channel allocator"}, @@ -83,8 +86,8 @@ {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:

+ stdlib, and sasl, as these applications are required + by ch_app. The file is called ch_rel-1.rel:

{release, {"ch_rel", "A"}, @@ -99,24 +102,28 @@
Generating Boot Scripts -

There are tools in the SASL module systools available to - build and check releases. The functions read the .rel and +

systools in the SASL application includes tools 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).

+ 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]).
 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.

+

This 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 .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:

+ from the .rel file are automatically loaded and started:

 % erl -boot ch_rel-1
 Erlang (BEAM) emulator version 5.3
@@ -147,18 +154,24 @@ Eshell V5.3  (abort with ^G)
   

     
     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.

+    
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").
 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.

+   
The release package by default contains:

+   
+     The .app files
+     The .rel file
+     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
@@ -177,40 +190,39 @@ 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
+    
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.

+      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 in order to make it possible for
+      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 (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.

+      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 is found, these files are included in
-      the release package as well. See
+      sys.config 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.

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

+    
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
-    
Directory structure for the code installed by the release handler
-      from a release package:

+    
The directory structure for the code installed by the release handler
+      from a release package is as follows:

     
 $ROOT/lib/App1-AVsn1/ebin
                     /priv
@@ -222,24 +234,18 @@ $ROOT/lib/App1-AVsn1/ebin
      /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:

+     
+       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 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
@@ -256,24 +262,24 @@ $THIRD_ROOT/TApp1-TAVsn1/ebin
            ...
            /TAppN-TAVsnN/ebin
                         /priv

-    
The $SECOND_ROOT and $THIRD_ROOT are introduced as
+    
$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
+      
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
-        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
+        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. Accordingly, the $ROOT
-        directory contains the following:

+        current release to the client. The $ROOT
+        directory thus contains the following:

       
 $ROOT/...
     /clients/ClientName1/bin
@@ -283,14 +289,14 @@ $ROOT/...
             ...
             /ClientNameN/bin
                         /releases/Vsn
-      
This structure should be used if all clients are running
+      
This 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 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
+        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 should be included:

+        directory are to be included:

       
 $ROOT/...
     /clients/Type1/lib
-- 
cgit v1.2.3