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.

一个完整的产品的发布周期如下:

1. 制作Release, 部署到目标机器 A(请参照前面章节)
2. 对代码进行bug修正,或功能完善,生成新的代码
3. 书写对应的.app文件和.rel文件
4. 对于每个修改过的application,书写对应的.appup文件, 此文件尤为重要, 其描述了application如何从一个版本,升级或回退到另一个版本.
5. 基于所有的.appup文件, 我们可以生成针对整个release的relup文件(通过releash_hanlder模块自动生成) (一个release会包含很多applications), 这个文件描述Release如何从一个版本升级或回退到另一个版本
6. 制作一个新的Release, 然后放置到待升级的目标机器 A
7. 在A中, 通过sasl的release handler模块对新的Release进行解压
8. 通过release hanlder执行relup文件安装新的Release.(可能包含很多操作)
9. 如果安装成功,现在新的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