更新: | 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 |
ビルドには rebar が必要です。rebar の最新版 2.5.1 以上を使ってください。
$ git clone [email protected]: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:
{release, {spam, "0.0.1"}, [sasl, spam]}.
まず設定ファイルはこれだけにします。
- ::
- $ ./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: '[email protected]' =PROGRESS REPORT==== 20-Sep-2014::15:59:55 === application: spam started_at: '[email protected]' Eshell V6.2 (abort with ^G) ([email protected])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 コマンドの引数から指定出来るものもいくつかありますので、そこをうまく組み合わせるのもありです。
そのあたりは後ほど開発用とリリース用の relx.config を紹介していきます。
通常の start_script では bin/<app> で起動してしまいます。rebar generate を使ったときのように start/sotp や console などを使えるようにするための仕組みです。コレはデフォルトで設定して良いでしょう。
{extended_start_script, true}.
erts ファイルつまり ErlangVM のファイル自体を含めるかどうかです。false にすると slim release と同様の仕組み、つまりパスに通ってる Erlang を使用します。開発版では false にしておくと良いでしょう。
{include_erts, false}.
default: | true |
---|
リリースしたファイルにソースコードを含めるかどうかです。開発中でもどうせ src/ をいじることになるので、false で問題ないと思います。
{include_src, false}.
default: | _rel |
---|
リリースしたファイルの置き先です。開発版は dev で、リリース版は pkg とかにしています。
{output_dir, "dev"}.
default: | false |
---|
開発モードでリリースします。deps などの依存ファイルがすべてシンボリックリンクになります。そのため rebar update-deps して compile すれば、その変更がすぐに反映されます。
{dev_mode, true}.
システム自体のグローバルな設定ファイルです。 rebar generate 時に rel/files/sys.config にあったファイルです。
指定しなければ自動で生成されます。
{sys_config, "rel/sys.config"}.
Erlang VM のパラメーターを埋め込みます。 rebar generate 時に rel/files/sys.config にあったファイルです。
{vm_args, "rel/vm.args"}.
リリースの設定です。この設定は複数書くことが出来ます。
{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"} のようにバージョンだけ設定することも可能です。
複数の release がある場合、デフォルトを設定出来ます。
{default_release, spam, "0.0.1"}.
パッケージ時に、ファイルを上書きしたりなどが出来ます。何でも出来てしまうので慎重に。
{overlay, [{mkdir, "log"}, {mkdir, "data"} ]}.
オーバーレイに使用するファイルを指定出来ます。開発版とリリース版で vars.config ファイル自体も分けると良さそうです。
{overlay_vars, "vars.config"}.
設定ファイルに存在しない拡張機能です。リストになっているのでいくつも設定可能です。デフォルトでいくつか用意されています。時前でも実装できます。
この後にいくつか紹介します。
{add_providers, [rlx_prv_archive]}.
relx の拡張機能です。
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 用のオプション的なもののため、展開するとフォルダを作ってくれなかったりとか色々期待している動作はしてくれません。
URL: | https://github.com/ehedenst/rlx_prv_cmd |
---|
公式では無くプラグイン的な感じのもの
あとで
あとで
あとで
relx をベースにするといくつか rebar generate で作成していたよりデフォルトの場合は制限がかかります。Erlang/OTP の rel モジュールで想定されている事を守る仕組みになっているためです。
app.config は本来は sys.config を使うべきのため存在しません。
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 とかでもいいのかもしれません。
入りが簡単で、リリースまでミスする場所少ないため、今後メインで使っていけるツールの一つだと思います。