erlang otp 应用发布指南(二) tiny-2.0 (supervisor)
Release Handling
Erlang的Release Handling, 充分利用Erlang的code hot swap特性, 让你的应用可以比较顺畅的进行升级,回退.
tiny-2.0
tiny-1.0已经成功的部署到了 /opt/local/tiny-1.0/ 目录. 最近，我们对tiny进行了改进, 准备要发布tiny-2.0. 我们在回想一下tiny-1.0, 在开始的时候提及过其不是一个真正的OTP application, 其没有supervisor, 没有gen_server等 OTP behavior. 在tiny-2.0中我们准备弥补这个"过错". 让tiny app更加的潇洒一些.
在tiny-2.0中,我们加入一个 src/tiny_server.erl , 其为用户提供 key-value 管理服务(gen_server). 在State中通过dict来保存所有的key-value pairs, 在这里就不罗列代码了, 你可以从附件的tiny-2.0中获取.
其主要接口如下:
%% @doc add the key value to server
add(Key, Value) ->
gen_server:call(?SERVER, {add, Key, Value}).
%% @doc delete the key from the server
delete(Key) ->
gen_server:call(?SERVER, {delete, Key}).
%% @doc get all the key-value list
all() ->
gen_server:call(?SERVER, {all}).
参照tiny-1.0,编译代码, 修改tiny_app.app和tiny-2.0.rel文件.
tiny_app.app:
{application, tiny_app,
[{description, "tiny app 2.0"},
{vsn, "2.0"},
{modules, [tiny, tiny_server]},
{registered, [tiny_sup, tiny_server]},
{applications, [kernel, stdlib, sasl]},
{mod, {tiny, []}}
]
}.
tiny-2.0.rel:
{release, {"tiny app release", "2.0"}, {erts, "5.6.5"},
[{kernel, "2.12.5"},
{stdlib, "1.15.5"},
{sasl, "2.1.5.4"},
{tiny_app, "2.0"}
]}.
现在tiny-2.0的目录结构和tiny-1.0一样.
书写appup文件
tiny-2.0的目的是为了升级tiny-1.0, 需要进行Release Handling.
SASL提供了进行代码热升级回退的基本框架, 因此需要支持这一特性的系统,必须包含: kernel, stdlib和sasl.
一个完整的产品的发布周期如下:
- 制作Release, 部署到目标机器 A(请参照前面章节)
- 对代码进行bug修正,或功能完善,生成新的代码
- 书写对应的.app文件和.rel文件
- 对于每个修改过的application,书写对应的.appup文件, 此文件尤为重要, 其描述了application如何从一个版本,升级或回退到另一个版本.
- 基于所有的.appup文件, 我们可以生成针对整个release的relup文件(通过releash_hanlder模块自动生成) (一个release会包含很多applications), 这个文件描述Release如何从一个版本升级或回退到另一个版本
- 制作一个新的Release, 然后放置到待升级的目标机器 A
- 在A中, 通过sasl的release handler模块对新的Release进行解压
- 通过release hanlder执行relup文件安装新的Release.(可能包含很多操作)
- 如果安装成功,现在新的Release成为默认版本.
系统不同的版本之间,推荐使用跨度比较小的多次升级, 而不是大相径庭的"一步到位", 因为 如果升级过程太复杂,那么系统出错的概率越高, 不可用的时间也越长.所以推荐平缓的小步升级. 更加详细的文档请参考 Release Handling .
好的理论说了一堆,现在该干实事了.
.appup文件的格式如下:
{Vsn,
[{UpFromVsn1, InstructionsU1},
...,
{UpFromVsnK, InstructionsUK}],
[{DownToVsn1, InstructionsD1},
...,
{DownToVsnK, InstructionsDK}]}.
Vsn是这个新的Release包中application的版本, UpFromVsn* 是一系列可以进行升级的先前版本, InstructionsU*是从这个先前版本升级到现在版本需要的动作. DownToVsn*是一系列可以回退到的旧版本, InstructionsD*是回退到对应旧版本需要的动作.
让我们创建tiny_app对应的.appup文件, tiny_app.appup:
{"2.0",
[{"1.0", [{restart_application, tiny_app}
]}],
[{"1.0", [{restart_application, tiny_app}
]}]
}.
因为我们的tiny-1.0不是一个真正的Erlang OTP application, 所以我们很不幸, 需要做一些大动作: restart_application 让我们重新启动了tiny_app, 这个似乎和我们一再鼓吹的 Erlang代码热替换的特性相左?
Release Handling给了我们很多命令, 我们可以加载,删除,更新module, 可以添加,删除,重启application, 甚至可以重启emulator. 但是回答上面的问题来, 我为什么重新启动了 application? 这是一个教训, 因为我的tiny-1.0匆匆上马, 其不是一个真正的OTP application. 我保证我下次不会这么鲁莽, 同时我承诺后面我会有tiny-3.0 :)
tiny_app.appup的含义就很简单了:我要从1.0升级到2.0, 只要重新启动tiny_app, 其会自动加载所有的modules; 我要从2.0回退到1.0, 只要重新启动tiny_app:其首先停止tiny-2.0版本, 随后卸载所有代码, 然后启动tiny-1.0.
我们将tiny_app.appup文件放置在ebin目录下.
如果有多个applications, 那么每个改动的application都要有一个对应的appup文件.
下面我们要生成relup文件
生成relup
这里还需要一个relup文件(release upgrade file), 用来描述整个Release如何进行升级回退,幸运的是 我们不用手写这个relup, 通过systools:make_relup(Name, UpFrom, DownTo)可以帮我们生成.
代码如下:
[da6600a1@litaocheng ~/install/tiny-2.0]$ erl -pa ../tiny-1.0/ ../tiny-1.0/ebin/ ./ebin/
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1> systools:make_relup("tiny-2.0", ["tiny-1.0"], ["tiny-1.0"]).
ok
(如果没有成功, 可能是你的路径错误, 还有就是appup的文件格式错误) 恩, 成功了, 在tiny-2.0目录下有一个relup文件.这个是我们想要的.
部署tiny-2.0
按照前面章节的介绍,生成一个新的release:
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1> systools:make_script("tiny-2.0").
ok
2> systools:make_tar("tiny-2.0").
ok
生成之后, 拷贝tiny-2.0.tar.gz到部署的机器(这里是本机), 将其放置在tiny-1.0安装目录 /opt/local/tiny的releases目录下:
[da6600a1@litaocheng ~/install/tiny-2.0]$ sudo cp tiny-2.0.tar.gz /opt/local/tiny/releases/
解压tiny-2.0.tar.gz:
[da6600a1@litaocheng /opt/local/tiny]$ ./bin/erl
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1> application:start(sasl).
2> release_handler:unpack_release("tiny-2.0").
{ok,"2.0"}
此时,在 /opt/local/tiny/releases/ 目录下出现了2.0的目录,其包含了tiny-2.0对应的relup, start.boot, 及tiny-2.0.rel 文件, 同时在 /opt/local/tiny/lib/ 目录下出现了 tiny-2.0 .
假设我们的tiny 1.0版本正在运行, 我们在对应shell中, 安装tiny-2.0:
1> tiny_app running...
tiny_app running...
2> release_handler:install_release("2.0").
=PROGRESS REPORT==== 9-Mar-2009::04:20:27 ===
supervisor: {<0.63.0>,tiny}
started: [{pid,<0.64.0>},
{name,tiny_server},
{mfa,{tiny_server,start_link,[]}},
{restart_type,permanent},
{shutdown,10},
{child_type,worker}]
=PROGRESS REPORT==== 9-Mar-2009::04:20:27 ===
application: tiny_app
started_at: nonode@nohost
{ok,"1.0",[]}
3> release_handler:make_permanent("2.0").
ok
从返回信息来看,我们成功的从1.0升级到了2.0, 让我们看看tiny-2.0是否被加载了:
3> application:which_applications().
[{tiny_app,"tiny app 2.0","2.0"},
{sasl,"SASL CXC 138 11","2.1.5.4"},
{stdlib,"ERTS CXC 138 10","1.15.5"},
{kernel,"ERTS CXC 138 10","2.12.5"}]
4> tiny_server:add(1, 234233).
ok
5> tiny_server:add(2, "hello").
ok
6> tiny_server:all().
[{2,"hello"},{1,234233}]
恩,的确现在已经是tiny-2.0了, make_permanent的目的是使tiny 2.0作为默认的版本.
好了,至此, release Handling我们也有了一定的了解.通过认真阅读OTP Design及不断的动手,相信你会对OTP Application的部署及升级会有清晰的认识.
(注意:新的release的安装必须在旧的code 所在erl进程进行,可以通过在新进程CTRL + G 相关命令链接old erl shell)
下一部分，我们将发布tiny-3.0