自动增量升级方案的设计及实现(2)

发表于:2013-08-29来源:IT博客大学习作者:zhengzn点击数: 标签:增量
#r2113:A:sub_dir/test/kkk2/tt2.txt r2124:A:sub_dir/conf/log4j.properties #r2197:A:sub_dir/conf #r2197:A:sub_dir/conf/config.conf xxxxx:A:sub_dir/db/patch.sql xxxxx:C:patch_script/demo_custom_script.sh

  #r2113:A:sub_dir/test/kkk2/tt2.txt

  r2124:A:sub_dir/conf/log4j.properties

  #r2197:A:sub_dir/conf

  #r2197:A:sub_dir/conf/config.conf

  xxxxx:A:sub_dir/db/patch.sql

  xxxxx:C:patch_script/demo_custom_script.sh:sub_dir/autoscript

  这里分几点来解释一下这个清单文件:

  1. 行首带#号的为注释行,gen_patch.sh不会解析。由于有些配置文件(如这里的config.conf)我们在版本库上虽做了修改,但我们不能更新到线上应用去,毕竟配置不一样,故直接把相应的行注释掉即可(注意记得把相应的目录也注释掉,如这里的”#r2197:A:sub_dir/conf “行)。

  2. 第一行是一个样例,标识每行记录需遵守的格式,一行最多只有4项,每项用冒号分隔。revision为版本号;A/D/C分别表示为“添加或修改 (Add)/删除(Delete)/自定义命令(Comand)“;src_file为涉及文件在版本库中的目录结构;dest_dir(这里是目录,而不是文件)为src_file在发布包中的目录结构,如果没指定则表示涉及的文件在版本库和发布包中的目录结构一样。

  3.后面的版本号为xxxxx的行是一些自定义操作行,这些操作并没有或者无法在版本库中体现。如

  xxxxx:A:sub_dir/db/patch.sql ===> patch.sql文件在指定的版本号范围内并没有相应的更改历史,也许它根本就不在版本库内,但我们又想让它随本次的增量包拷贝到线上应用去,所以采用这种定制的方式委婉的将它纳入增量包中。

  4.值得注意的是操作为"C"的行,如这里的最后一行:

  xxxxx:C:patch_script/demo_custom_script.sh:sub_dir/autoscript ===>C操作的行并非简单的表示将src_file拷贝到dest_dir,事实上它并没有被拷贝到线上应用中去,而只是仅仅打进增量包中,然后作为一种自动化的程序,在运维人员执行升级(patch.sh)操作时被自动执行的程序,有点被回调的味道。该程序一般需要开发人员根据实际需要编写,一般是一些执行服务的操作,如重启某些服务。如这里提到的demo_custom_script.sh:

  自定义升级脚本demo_custom_script.sh:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/bin/env bash
 
src_dir=$1  ### 由升级程序patch.sh传递进来,表示增量包在线上被解压的临时目录
dest_dir=$2 ### 由升级程序patch.sh传递进来,表示线上应用所在的目录(即patch.sh所在的目录)
 
export LANG=en_US.UTF-8
 
target_dir=my_target/bin
target_proc=my_service
 
function err_out()
{
echo "Reload my_service failed"    >&2
    exit 1
}
 
cd $dest_dir/$target_dir && \
./my_service reload  ### 升级时(一般是执行完增量清单中的其它操作之后)重启我的服务
 
if [ $? -ne 0 ]; then
err_out
fi
 
exit 0

  生成增量包gen_patch.sh:

  $ ./gen_patch.sh

  Usage: ./gen_patch.sh

 

  

: patch file like -patch20130607.tar.gz will be generated

  Attention: a manifest file named 'PATCH_MANIFEST' is needed under current directory

  gen_patch.sh的功能很简单,就是根据之前生成的清单文件PATCH_MANIFEST生成增量包,所以前提是确保清单文件是准确的,当然也可以通过查看生成后的增量包是否符合实际要求来进一步确认。

  执行升级操作patch.sh:

  $ ./patch.sh

  Usage: ./patch.sh patch.tar.gz

  顾名思义,该脚本的作用就是用于给当前的应用打上补丁,一般由线上的运维人员执行。该脚本应该在程序第一次发布的时候包含进去,且应该与放置应用代码的根目录同级。如下

  myapp-1.1.0-rc5-bin-x86_64

  |- approot

  |- app-patch20130624.tar.gz

  |- patch.sh

  |- patch_recover_20130613182709 ===> 升级时生成的增量回滚快照

  |- patch_20130626.log ===> 升级时执行的日志

  其中的app-patch20130624.tar.gz即为前面通过gen_patch.sh生成的增量升级包,而 patch_recover_20130613182709目录是执行升级前自动生成的增量备份,如果发现升级有误的话,可立即通过将该备份目录下的内容拷回原来的位置,即可完成回滚。

  结束:

  虽然前面洋洋洒洒写了好多,感觉好像很复杂的样子,其实想要表达意思的很简单,就下面三个步骤:

  生成增量包:

  $ ./gen_manifest.sh 2061 >PATCH_MANIFEST

  $ ./gen_patch.sh app ===>生成app-patch20130624.tar.gz

  执行升级:

  $ ./patch.sh app-patch20130624.tar.gz

原文转自:http://blogread.cn/it/article/6550?f=wb