Navigation

Table Of Contents

Previous topic

9. 分散アプリケーション

Next topic

11. リリース・ハンドリング

This Page

10. リリース

この章を読む場合には、rel(4)、systools(3)、script(4)も合わせてお読みください。

10.1. リリースの概念

もしアプリケーションをいくつか作成したのであれば、これらのアプリケーションや、Erlang/OTPアプリケーションのサブセットから構成される、完全なシステムを作りたいと思うでしょう。これは リリース と呼ばれます。

これを行うためには、どのアプリケーションをリリースに含めるかを定義した、 リリース・リソースファイル を作成します。

リリース・リソースファイル は ブートスクリプト と リリースパッケージの作成 を作るのに使用されます。

10.2. リリース・リソースファイル

リリースを定義するには、リリース・リソースファイル(.relファイルとも呼ばれる)を作成します。このファイルにはリリースの名前、バージョン、どのERTSバージョンを元にしているか、どのアプリケーションから構成されるのか、を定義していきます。

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

ファイル名は Rel.rel という名前にします。 Rel はユニークな名前にします。

Name, Vsn, Evsn には文字列を設定します。

それぞれの Application (アトム)と AppVsn (文字列)は、リリースに含まれるアプリケーションの名前とバージョンをsて呈します。Erlang/OTPのリリースを構成する最小のものは、 kernel と stdlib アプリケーションであるため、これらのアプリケーションは必ずリストに含めなければなりません。

それでは、 applications: の章で紹介した ``ch_app` のリリースをしたいと思ったとします。この場合、次のような .app ファイルになります。

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

ch_app の実行に必要であるため、 .rel ファイルには kernel と stdlib 、 sasl を含めなければなりません。次のような 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. ブートスクリプトの作成

リリースのビルドとチェックに使えるツールが、SASLモジュール systoolsに含まれます。これらの関数は、 .rel 、 .app ファイルを読み込み、文法の評価と依存性チェックをします。 systools:make_script/1,2 という関数が、ブートスクリプトの生成に利用されます。 (system_principles 参照)

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

この関数は、人が読むことができるバージョンの ch_rel-1.script``というファイルと、ランタイムシステムから使用される、バイナリバージョンの ``ch_rel-1.boot の、両方の形式のファイルが生成されます。 "ch_rel-1" という名前は、 .rel ファイルから、拡張子を取った名前です。オプションの local を指定すると、 $ROOT/lib によらず、ブートスクリプトのあるディレクトリから、アプリケーションが探索されます。($ROOT リリースがインストールされたディレクトリのルートです。これは、生成されたブートスクリプトをローカルでテストするには便利な方法です。

ブートスクリプトを使用してErlang/OTPを起動する場合、 .rel ファイルに含まれるすべてのアプリケションを自動的にロードして、スタートします。

% 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. リリースパッケージの作成

.rel ファイルを入力に取り、特定のアプリケーションのコードをtar.gzにまとめて、リリースパッケージを作成する、 systools:make_tar/1,2 関数があります。

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

リリースパッケージには、デフォルトで .app ファイルと、すべてのアプリケーションに関する、すべてのオブジェクトコードが含まれ、アプリケーションのディレクトリ構造に従って格納されます。バイナリのブートスクリプトは start.boo にリネームされて含まれます。また、 .rel ファイルも格納されます。

% 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/ch_rel-1.rel

これを実行すると、リリースパッケージの作成前に local オプションなしで新しいブートスクリプトが生成されます。リリースパッケージ内では、すべてのアプリケーションディレクトリは lib ディレクトリの中に配置されます。リリースパッケージがどのディレクトリにインストールされるかは知りませんが、このブートスクリプトには絶対パスをハードコードする必要はありません。

もし、 relup ファイルと、 sys.config という名前のシステム設定ファイルの両方、もしくはどちらかが見つかった場合には、これらのファイルも同じようにリリースパッケージに含まれます。これについては リリース・ハンドリング を参照してください。

リリースパッケージに、ソースコードやERTSバイナリも同じように含めるようなオプションもあります。

リリースパッケージを使用して、最初のターゲットシステムのインストールを行う方法については、 system_principles を参照してください。また、既存のシステムに新しいリリースパッケージをインストールする方法については、 リリース・ハンドリング を参照してください。

10.5. ディレクトリ構造

リリースハンドラによってインストールされるディレクトリの構造については release package と同様です。

$ROOT/lib/App1-AVsn1/ebin
                    /priv
         /App2-AVsn2/ebin
                    /priv
         ...
         /AppN-AVsnN/ebin
                    /priv
     /erts-EVsn/bin
     /releases/Vsn
     /bin
lib
アプリケーションディレクトリ。
erts-EVsn/bin
Erlang ランタイムシステムの実行ファイル。
releases/Vsn
.rel ファイルと、ブートスクリプトの start.boot です。もしリリースパッケージ内に relup や sys.config があれば、それも格納されます。
bin
トップレベルのErlangランタイムシステムの実行形式です。

アプリケーションは、 $ROOT/lib ディレクトリの下に置く必要はありません。そのため、システムをいくつかの部品に分けて、複数のディレクトリにインストールすることもできます。例えば、前のサンプルは次のような配置に拡張することもできます。

$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

この $SECOND_ROOT と $THIRD_ROOT は systools:make_script/2 関数呼び出しの中で変数として導入されたものです。

10.5.1. ディスクレス and/or 読み込み専用クライアント

もし、全体のシステムの中に、ディスクレスのノードや、読み込み専用のノードが含まれる場合は、 clients ディレクトリを $ROOT ディレクトリに追加すべきでしょう。ここで言う読み込み専用のノードというのは、読み込み専用のファイルシステムを持つノードという意味です。

clients ディレクトリは、サポートするクライアントのノード1つごとに1つのサブディレクトリを持ちます。各サブディレクトリの名前は、関連するクライアントノードの名前を付けます。少なくとも、それぞれのクライアントのディレクトリには、 bin と releases というサブディレクトリが含まれます。これらのディレクトリは、インストールされているリリースの情報を格納したり、現在のリリースを指定するのに使用します。 $ROOT は次のような構成になります。

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

すべてのクライアントで同じ種類のErlangマシンを使用しているのであれば、このディレクトリ構造を使用すべきです。もし、一部のノードのOSや、Erlangマシンの種類が異なるという場合には、Erlangマシンの種類ごとにサブディレクトリに分割すべきです。これ以外の方法としては、マシンの種類ごとに $ROOT を設定することもできます。 $ROOT には、それぞれの種類のディレクトリを含むべきです。

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

この構造の場合、 Type1 のクライアントのルートディレクトリは $ROOT/clients/Type1 となります。

Copyright (c) 1991-2009 Ericsson AB

Navigation

© Copyright 2010, Ericsson AB.. Created using Sphinx 1.0.4.