1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
<TITLE>Releases</TITLE>
<SCRIPT type="text/javascript" src="../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="10"><!-- Empty --></A>
<H2>10 Releases</H2>
<P>This chapter should be read in conjuction with <CODE>rel(4)</CODE>,
<CODE>systools(3)</CODE> and <CODE>script(4)</CODE>.<A NAME="10.1"><!-- Empty --></A>
<H3>10.1 Release Concept</H3>
<P>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
<STRONG>release</STRONG>.
<P>To do this, we create a <A HREF="#res_file">release
resource file</A> which defines which applications
are included in the release.
<P>The release resource file is used to generate
<A HREF="#boot">boot scripts</A> and
<A HREF="#pack">release packages</A>. A system
which is transfered to and installed at another site is called a
<STRONG>target system</STRONG>. How to use a release package to create a
target system is described in System Principles.<A NAME="res_file"><!-- Empty --></A><A NAME="10.2"><!-- Empty --></A>
<H3>10.2 Release Resource File</H3>
<P>To define a release, we create a <STRONG>release resource file</STRONG>,
or in short <CODE>.rel</CODE> file, where we specify the name and
version of the release, which ERTS version it is based on, and
which applications it consists of:
<PRE>
{release, {Name,Vsn}, {erts, EVsn},
[{Application1, AppVsn1},
...
{ApplicationN, AppVsnN}]}.
</PRE>
<P>The file must be named <CODE>Rel.rel</CODE>, where <CODE>Rel</CODE> is a
unique name.
<P><CODE>Name</CODE>, <CODE>Vsn</CODE> and <CODE>Evsn</CODE> are strings.
<P>Each <CODE>Application</CODE> (atom) and <CODE>AppVsn</CODE> (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 <CODE>kernel</CODE> and <CODE>stdlib</CODE> applications, so these
applications must be included in the list.<A NAME="ch_rel"><!-- Empty --></A>
<P>Example: We want to make a release of <CODE>ch_app</CODE> from
the <A HREF="applications.html#ch_app">Applications</A>
chapter. It has the following <CODE>.app</CODE> file:
<PRE>
{application, ch_app,
[{description, "Channel allocator"},
{vsn, "1"},
{modules, [ch_app, ch_sup, ch3]},
{registered, [ch3]},
{applications, [kernel, stdlib, sasl]},
{mod, {ch_app,[]}}
]}.
</PRE>
<P>The <CODE>.rel</CODE> file must also contain <CODE>kernel</CODE>,
<CODE>stdlib</CODE> and <CODE>sasl</CODE>, since these applications are
required by <CODE>ch_app</CODE>. We call the file <CODE>ch_rel-1.rel</CODE>:
<PRE>
{release,
{"ch_rel", "A"},
{erts, "5.3"},
[{kernel, "2.9"},
{stdlib, "1.12"},
{sasl, "1.10"},
{ch_app, "1"}]
}.
</PRE>
<A NAME="boot"><!-- Empty --></A><A NAME="10.3"><!-- Empty --></A>
<H3>10.3 Generating Boot Scripts</H3>
<P>There are tools in the SASL module <CODE>systools</CODE> available to
build and check releases. The functions read the <CODE>.rel</CODE> and
<CODE>.app</CODE> files and performs syntax and dependency checks.
The function <CODE>systools:make_script/1,2</CODE> is used to generate
a boot script (see System Principles).
<PRE>
1> <STRONG>systools:make_script("ch_rel-1", [local]).</STRONG>
ok
</PRE>
<P>This creates a boot script, both the readable version
<CODE>ch_rel-1.script</CODE> and the binary version used by the runtime
system, <CODE>ch_rel-1.boot</CODE>. <CODE>"ch_rel-1"</CODE> is the name of
the <CODE>.rel</CODE> file, minus the extension. <CODE>local</CODE> is an
option that means that the directories where the applications are
found are used in the boot script, instead of <CODE>$ROOT/lib</CODE>.
(<CODE>$ROOT</CODE> is the root directory of the installed release.)
This is a useful way to test a generated boot script locally.
<P>When starting Erlang/OTP using the boot script, all applications
from the <CODE>.rel</CODE> file are automatically loaded and started:
<PRE>
% <STRONG>erl -boot ch_rel-1</STRONG>
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
</PRE>
<A NAME="pack"><!-- Empty --></A><A NAME="10.4"><!-- Empty --></A>
<H3>10.4 Creating a Release Package</H3>
<P>There is a function <CODE>systools:make_tar/1,2</CODE> which takes
a <CODE>.rel</CODE> file as input and creates a zipped tar-file with
the code for the specified applications, a <STRONG>release
package</STRONG>.
<PRE>
1> <STRONG>systools:make_script("ch_rel-1").</STRONG>
ok
2> <STRONG>systools:make_tar("ch_rel-1").</STRONG>
ok
</PRE>
<P>The release package by default contains the <CODE>.app</CODE> files and
object code for all applications, structured according to
the <A HREF="applications.html#app_dir">application directory
structure</A>, the binary boot script renamed to
<CODE>start.boot</CODE>, and the <CODE>.rel</CODE> file.
<PRE>
% <STRONG>tar tf ch_rel-1.tar</STRONG>
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/ch_rel-1.rel
</PRE>
<P>Note that a new boot script was generated, without
the <CODE>local</CODE> option set, before the release package was made.
In the release package, all application directories are placed
under <CODE>lib</CODE>. 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.
<P>If a <CODE>relup</CODE> file and/or a system configuration file called
<CODE>sys.config</CODE> is found, these files are included in
the release package as well. See
<A HREF="release_handling.html#req">Release Handling</A>.
<P>Options can be set to make the release package include source
code and the ERTS binary as well.
<P>Refer to System Principles for how to install the first target
system, using a release package, and to
<A HREF="release_handling.html">Release Handling</A> for
how to install a new release package in an existing system.<A NAME="reldir"><!-- Empty --></A><A NAME="10.5"><!-- Empty --></A>
<H3>10.5 Directory Structure</H3>
<P>Directory structure for the code installed by the release handler
from a release package:
<PRE>
$ROOT/lib/App1-AVsn1/ebin
/priv
/App2-AVsn2/ebin
/priv
...
/AppN-AVsnN/ebin
/priv
/erts-EVsn/bin
/releases/Vsn
/bin
</PRE>
<P>
<DL>
<DT>
<CODE>lib</CODE>
</DT>
<DD>
Application directories.
</DD>
<DT>
<CODE>erts-EVsn/bin</CODE>
</DT>
<DD>
Erlang runtime system executables.
</DD>
<DT>
<CODE>releases/Vsn</CODE>
</DT>
<DD>
<CODE>.rel</CODE> file and boot script <CODE>start.boot</CODE>.<BR>
If present in the release package,<BR>
<CODE>relup</CODE> and/or <CODE>sys.config</CODE>.
</DD>
<DT>
<CODE>bin</CODE>
</DT>
<DD>
Top level Erlang runtime system executables.
</DD>
</DL>
<P>Applications are not required to be located under the
<CODE>$ROOT/lib</CODE> directory. Accordingly, several installation
directories may exist which contain different parts of a
system. For example, the previous example could be extended as
follows:
<PRE>
$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
</PRE>
<P>The <CODE>$SECOND_ROOT</CODE> and <CODE>$THIRD_ROOT</CODE> are introduced as
<CODE>variables</CODE> in the call to the <CODE>systools:make_script/2</CODE>
function.<A NAME="10.5.1"><!-- Empty --></A>
<H4>10.5.1 Disk-Less and/or Read-Only Clients</H4>
<P>If a complete system consists of some disk-less and/or
read-only client nodes, a <CODE>clients</CODE> directory should be
added to the <CODE>$ROOT</CODE> directory. By a read-only node we
mean a node with a read-only file system.
<P>The <CODE>clients</CODE> 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 <CODE>bin</CODE> and
<CODE>releases</CODE> sub-directories. These directories are used to
store information about installed releases and to appoint the
current release to the client. Accordingly, the <CODE>$ROOT</CODE>
directory contains the following:
<PRE>
$ROOT/...
/clients/ClientName1/bin
/releases/Vsn
/ClientName2/bin
/releases/Vsn
...
/ClientNameN/bin
/releases/Vsn
</PRE>
<P>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 <CODE>clients</CODE> directory could be divided into one
sub-directory per type of Erlang machine. Alternatively, you
can set up one <CODE>$ROOT</CODE> per type of machine. For each
type, some of the directories specified for the <CODE>$ROOT</CODE>
directory should be included:
<PRE>
$ROOT/...
/clients/Type1/lib
/erts-EVsn
/bin
/ClientName1/bin
/releases/Vsn
/ClientName2/bin
/releases/Vsn
...
/ClientNameN/bin
/releases/Vsn
...
/TypeN/lib
/erts-EVsn
/bin
...
</PRE>
<P>With this structure, the root directory for clients of
<CODE>Type1</CODE> is <CODE>$ROOT/clients/Type1</CODE>.<CENTER>
<HR>
<SMALL>
Copyright © 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>
|
