relx コトハジメ

relx.rst

relx コトハジメ

更新:	2014-09-22
バージョン:	0.2.1
作者:	@voluntas
URL:	https://voluntas.github.io/

概要

URL:	https://github.com/erlware/relx

relx は erlware が開発している、 Erlang/OTP リリースツールです。 完全にリリース特化ツールですので、リリース以外のことは出来ません。

rebar の generate より気軽に使うことが出来ます。

ドキュメントがあまりないので、まとめるつもりで書いていきます。

環境

試した環境は以下の通りです

Erlang/OTP:	Erlang/OTP 17 erts-6.2 64-bit
Rebar:	rebar 2.5.1 17 20140920_050239 git 2.5.1-15-g4e378a4

relx の準備

ビルドには rebar が必要です。rebar の最新版 2.5.1 以上を使ってください。

$ git clone git@github.com:erlware/relx.git
$ make

これで relx というバイナリが出来ていれば成功です。

サンプルアプリの準備

アプリ名:	spam

$ mkdir spam
$ cd spam
$ cp /path/to/rebar .
$ cp /path/to/relx .
$ ./rebar create-app appid=spam
==> spam (create-app)
Writing src/spam.app.src
Writing src/spam_app.erl
Writing src/spam_sup.erl

後々見栄えが悪いので src の下の spam.app.src の vsn を "1" から "0.0.1" に書き換えます。

src/spam.app.src:

{application, spam,
 [
  {description, ""},
  {vsn, "0.0.1"},
  {registered, []},
  {applications, [
                  kernel,
                  stdlib
                 ]},
  {mod, { spam_app, []}},
  {env, []}
 ]}.

relx.config の準備

relx.config ファイルを作ります

relx.config:

{release, {spam, "0.0.1"},
 [sasl, spam]}.

まず設定ファイルはこれだけにします。

relx を実行してみる

::

$ ./rebar compile $ ./relx

$ ./relx
===> Starting relx build process ...
===> Resolving OTP Applications from directories:
          /path/to/spam/ebin
          /opt/erlang/17.3/lib/erlang/lib
===> Resolving available OTP Releases from directories:
          /path/to/spam/ebin
          /opt/erlang/17.3/lib/erlang/lib
===> Resolved spam-0.0.1
===> Including Erts from /opt/erlang/17.3/lib/erlang
===> release successfully created!

_rel というフォルダが出来ていると思います。これでリリースファイルができあがりました。

とても簡単ですね ... 。いままで reltool.config をいじっていた時間を返して欲しいですね。

動かしてみましょう。

sasl を指定しているので最初に色々出てくるかもしれませんが気にしないでください。

$ _rel/spam/bin/spam
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]


=PROGRESS REPORT==== 20-Sep-2014::15:59:55 ===
          supervisor: {local,sasl_safe_sup}
             started: [{pid,<0.41.0>},
                       {name,alarm_handler},
                       {mfargs,{alarm_handler,start_link,[]}},
                       {restart_type,permanent},
                       {shutdown,2000},
                       {child_type,worker}]

=PROGRESS REPORT==== 20-Sep-2014::15:59:55 ===
          supervisor: {local,sasl_safe_sup}
             started: [{pid,<0.42.0>},
                       {name,overload},
                       {mfargs,{overload,start_link,[]}},
                       {restart_type,permanent},
                       {shutdown,2000},
                       {child_type,worker}]

=PROGRESS REPORT==== 20-Sep-2014::15:59:55 ===
          supervisor: {local,sasl_sup}
             started: [{pid,<0.40.0>},
                       {name,sasl_safe_sup},
                       {mfargs,
                           {supervisor,start_link,
                               [{local,sasl_safe_sup},sasl,safe]}},
                       {restart_type,permanent},
                       {shutdown,infinity},
                       {child_type,supervisor}]

=PROGRESS REPORT==== 20-Sep-2014::15:59:55 ===
          supervisor: {local,sasl_sup}
             started: [{pid,<0.43.0>},
                       {name,release_handler},
                       {mfargs,{release_handler,start_link,[]}},
                       {restart_type,permanent},
                       {shutdown,2000},
                       {child_type,worker}]

=PROGRESS REPORT==== 20-Sep-2014::15:59:55 ===
         application: sasl
          started_at: 'spam@127.0.0.1'

=PROGRESS REPORT==== 20-Sep-2014::15:59:55 ===
         application: spam
          started_at: 'spam@127.0.0.1'
Eshell V6.2  (abort with ^G)
(spam@127.0.0.1)1>

無事アプリケーションが動作しました。これ以上はありません。あとは relx.config に書いていく設定知識を増やしていきましょう。

参考までにリリース後のフォルダ構造を。

• erts-6.2
  • ErlangVM です
• lib
  • relx で releases で指定したアプリです

フォルダ構造:

_rel/
    spam/
        bin/
            spam
            spam-0.0.1
        erts-6.2/
            ...
        lib/
            kernel-3.0.3/
            sasl-2.4.1/
            spam-0.0.1/
            stdlib-2.2/
        releases/
            0.0.1/
                spam.boot
                spam.rel
                spam.script
                sys.config
                vm.args
            RELEASES
            start_erl.data

relx.config

アンドキュメントな設定も書き出しています。

実は relx コマンドの引数から指定出来るものもいくつかありますので、そこをうまく組み合わせるのもありです。

そのあたりは後ほど開発用とリリース用の relx.config を紹介していきます。

extended_start_script

通常の start_script では bin/<app> で起動してしまいます。rebar generate を使ったときのように start/sotp や console などを使えるようにするための仕組みです。コレはデフォルトで設定して良いでしょう。

{extended_start_script, true}.

include_erts

erts ファイルつまり ErlangVM のファイル自体を含めるかどうかです。false にすると slim release と同様の仕組み、つまりパスに通ってる Erlang を使用します。開発版では false にしておくと良いでしょう。

{include_erts, false}.

include_src

default:	true

リリースしたファイルにソースコードを含めるかどうかです。開発中でもどうせ src/ をいじることになるので、false で問題ないと思います。

{include_src, false}.

output_dir

default:	_rel

リリースしたファイルの置き先です。開発版は dev で、リリース版は pkg とかにしています。

{output_dir, "dev"}.

dev_mode

default:	false

開発モードでリリースします。deps などの依存ファイルがすべてシンボリックリンクになります。そのため rebar update-deps して compile すれば、その変更がすぐに反映されます。

{dev_mode, true}.

sys_config

システム自体のグローバルな設定ファイルです。 rebar generate 時に rel/files/sys.config にあったファイルです。

指定しなければ自動で生成されます。

{sys_config, "rel/sys.config"}.

vm_args

Erlang VM のパラメーターを埋め込みます。 rebar generate 時に rel/files/sys.config にあったファイルです。

{vm_args, "rel/vm.args"}.

release

リリースの設定です。この設定は複数書くことが出来ます。

{release, {spam, "0.0.1"},
 [sasl, spam]}.

{release, {spam, "0.1.1"},
 [sasl, crypto, spam]}.

モジュール指定のところはかなり細かく書くことも出来ます。

crypto を {crypto, "2.0.0", '>='} のようにライブラリのバージョンの範囲を設定することも出来ます。

{release, {spam, "0.0.1"},
 [sasl, spam]}.

{release, {spam, "0.1.1"},
 [sasl, {crypto, "2.0.0", '>='}, spam]}.

もちろん {crypto, "2.0.0"} のようにバージョンだけ設定することも可能です。

default_release

複数の release がある場合、デフォルトを設定出来ます。

{default_release, spam, "0.0.1"}.

overlay

パッケージ時に、ファイルを上書きしたりなどが出来ます。何でも出来てしまうので慎重に。

{overlay, [{mkdir, "log"},
           {mkdir, "data"}
          ]}.

overlay_vars

オーバーレイに使用するファイルを指定出来ます。開発版とリリース版で vars.config ファイル自体も分けると良さそうです。

{overlay_vars, "vars.config"}.

add_providers

設定ファイルに存在しない拡張機能です。リストになっているのでいくつも設定可能です。デフォルトでいくつか用意されています。時前でも実装できます。

この後にいくつか紹介します。

{add_providers, [rlx_prv_archive]}.

providers

relx の拡張機能です。

rlx_prv_archive

tar.gz パッケージを生成してくれます。

relx.config に add_providers で rlx_prv_archive を追加します。

relx.config:

{release, {spam, "0.0.1"},
 [sasl, spam]}.

{add_providers, [rlx_prv_archive]}.

実行してみます。最後に tarball が出来ているのがわかります。

$ ./relx
===> Starting relx build process ...
===> Resolving OTP Applications from directories:
          /path/to/spam/ebin
          /opt/erlang/17.3/lib/erlang/lib
          /path/to/spam/_rel
===> Resolving available OTP Releases from directories:
          /path/to/spam/ebin
          /opt/erlang/17.3/lib/erlang/lib
          /path/to/spam/_rel
===> Resolved spam-0.0.1
===> Including Erts from /opt/erlang/17.3/lib/erlang
===> release successfully created!
===> tarball /path/to/spam/_rel/spam/spam-0.0.1.tar.gz successfully created!

ただし、この機能自体は relup 用のオプション的なもののため、展開するとフォルダを作ってくれなかったりとか色々期待している動作はしてくれません。

rlx_prv_cmd

URL:	https://github.com/ehedenst/rlx_prv_cmd

公式では無くプラグイン的な感じのもの

あとで

開発版

あとで

リリース版

あとで

注意点

relx をベースにするといくつか rebar generate で作成していたよりデフォルトの場合は制限がかかります。Erlang/OTP の rel モジュールで想定されている事を守る仕組みになっているためです。

app.config がない

app.config は本来は sys.config を使うべきのため存在しません。

etc/* から読み込めない

relx での設定ファイルは releases/0.0.1/sys.config などのように releases フォルダの下のバージョン番号の下に設定ファイルが置かれる仕組みになります。そのため今までのようなトップレベルの設定ファイルは作成できません。

ただ所詮シェルスクリプトなので色々いじれば出来ます。

sys.config を強制的に指定させられたり、vm.args の読み込みも固定されたりしているので ... このあたりを書き直せば設定可能です。

REL_DIR="$RELEASE_ROOT_DIR/releases/$REL_VSN"

find_sys_config() {
    local possible_sys="$REL_DIR/sys.config"
    if [ -f "$possible_sys" ]; then
        SYS_CONFIG="$possible_sys"
    fi
}

生成されるたスクリプトをベースに書き直したファイルを用意しておき overlay で書き直せば出来ます。

感想

rebar generate と比べると準備するものがほとんどなく、リリースがとても簡単です。またパッケージングも含まれているためあまり難しく考える必要は無いでしょう。

ただ、シンプルに使えるようになっている以上は複雑なことを使用とした場合 rebar generate に戻る必要が出てきます。

そのため、開発では relx 、リリースは rebar generate とかでもいいのかもしれません。

入りが簡単で、リリースまでミスする場所少ないため、今後メインで使っていけるツールの一つだと思います。