RPM打包利器RPM_CREATE
RPM 是 Redhat Package Manager 的简称,是由 redhat 公司研制,用在 Linux 系统下的系统包管理工具。 RPM 包目的:是使软件包的安装和卸载过程更容易,简化软件包的建立分发过程,并能用于不同的体系结构, RPM 系统已成为现在 Linux 系统下包管理工具事实上的标准,并且已经移植到很多商业的 unix 系统之下 。
rpm 打包可以通过编写 spec 文件,使用 rpmbuild 来完成一个 rpm 的打包。
使用 spec 文件的方式打包,对于初学者最难理解的是 install 和 file 节点编写的关系,并且复杂的是,还需要学习 spec 语言中特有的语法和环境变量关系。其次是打包过程,打 rpm 包前需要先把打包的内容,打成 tar.gz 的包,然后拷贝到 rpmbuild 的源码目录内,大部分是 /usr/src/redhat/SOURCES 这个目录,之后再把 spec 文件拷贝到 /usr/src/redhat/SPECS 目录,然后执行打包命令 rpmbuild –bb xxx.spec ,到 /usr/src/redhat/rpms/i386(32 位系统 ) 找到新打的包。当然整个过程可以编写 shell 脚本来模拟上述步骤,最终得到打包后的文件。但是 shell 脚本必须和每个项目结合起来,也就是每开一个项目,都要编写与之对应的一个 shell 文件,并且一样要编写 spec 文件,这并没有彻底解决使用 spec 打包的繁琐问题。
学习使用 rpmbuild 打包,学习曲线比较陡峭,并且整个打包过程比较繁琐,尤其当一个产品上线时,如果发现一个 bug ,需要快速修改调用,那么快速打新包是必须,因为线上环境每晚一刻就可能影响数千人的用户体验,而采用 rpmbuild 的方式整个过程非常繁琐,有没有更好更快的方式,作为参考有 checkinstall 。
checkinstall 是一个能从 tar.gz 类的源代码自动生成 RPM / Debian 或 Slackware 安装包的程序。通过 checkInstall ,你就能用几乎所有的 tar.gz 类的源代码来生成“干净”的安装或者卸载包。
checkinstall 的使用非常方便,可以从 checkinstall-1.6.1-1.i386.rpm 获取 checkinstall 的 rpm 包,直接部署到我们的机器上,但是我们要打造自己的 checkinstall ,所以我们最好下载源代码来, 获取源代码 。
checkinstall 的原理是追踪 makefile 中的 install 操作(其实是 checkinstall 中的 installwatch 完成此项工作),记录下整个文件相关变化,并最终生成 spec 文件,然后执行 rpmbuild 打包操作,完成打包过程。
但是真实使用 checkinstall 打包时,有个难题。 checkinstall 获取版本号默认的是通过目录名获取的,也就是说我们每次更新一下包都需要更改目录名,当然版本号也可以采用手工输入的方式,面临同样问题的还有包的名称,释放版本号,包依赖,打包者,版权,简介等,这些信息每次打包时,都需要重复填写,对于我们偶尔打个包,这种输入是无所谓的,但是如果频繁打包的话,这样的过程会非常繁琐,并且还容易出错。看我们碰到的问题是, spec 文件难写,打包繁琐; checkinstall 只需要些 makefile 文件的 install 操作即可打包,脚本编写简单,但是交互太多,所以,我决定开发一种新的打包方式,简化流程,并结合 spec 和 checkinstall 的优点,这就是 rpm_create 。
rpm_create 打包时,只需要编写 citb 格式文件,当然你会说, rpm_create 一样需要些打包的配置文件,并没有简化流程。是的, rpm_create 一样需要编写打包配置文件,流程似乎没有改变,其实不对。看看 citb 文件格式就知道,下面是 rpm_create 带的实例文件,安装 rpm_create 后, /usr/local/lib/checkinstall/example.citb 既是文件。
###############################################################
# author: ugg
# mail: ugg.xchj@gmail.com
# url: https://code.google.com/p/rpmcreate/
###############################################################
# 需要包的名称
Name: tpm_create_test
# 包的版本信息
Version: 1.0.0
# 释放版本号
Release: 1
# 依赖包
Requires: php , httpd
# 创建者
Packager: ugg
# 摘要信息
Summary: by ugg test
# 版权
copyright: company
# 指定包目标环境平台( i386 对应 32 系统, x86_64 对应 64 系统, noarch 不区分系统)
Architecture: noarch
PEARPATH=/usr/lib/php/pear/tbs/apps/customhtml
HTDOCSPATH=/var/www/htdocs/apps/customhtml
# 安装脚本开始命令 , 以下部分可以从和 Makefile 中的内容相同即可
install:
mkdir -p $(PEARPATH)
mkdir -p $(HTDOCSPATH)
cp -r ../../src/htdocs/*.php $(PEARPATH)/customhtml
cp -r ../../src/pear/*.php $($HTDOCSPATH)/customhtml
# 以下 shell 命令,要以 TAB 开始每一行
pre:
# 每行命令以 TAB 开始 , 安装包前执行命令
# sudo apachectl restart
preun:
# 每行命令以 TAB 开始 , 卸载包前执行命令
# sudo apachectl restart
postun:
# 每行命令以 TAB 开始 , 卸载包后前执行命令
# sudo apachectl restart
post:
# 每行命令以 TAB 开始 , 删除目录机上的 .svn 目录,安装包后执行
# 注意 find 命令后面的路径必须为目录机上的全路径,不能用其他变量替换全路径
# find /usr/lib/php/pear/tbs/apps/customhtml -type d -name ".svn"|xargs rm -rf
# find /var/www/htdocs/apps/customhtml -type d -name ".svn"|xargs rm -rf
# 打包日志,同 rpm 中的 %changelog
changelog:
# 每行日志以 TAB 开始
* Wed May 20 2009 changjing.xu %{Version}
整个打包配置文件就是如此简单,需要打包时。您只需要更改包的名称,版本号,文件拷贝工作通过 install 节点完成。 Install 里面的操作很简单,就是写 shell 基本即可
比方说,我们和 .citb 文件同级目录下的 test.php 文件,打包安装目标机的 /var/www/htdocs 目录下,那么我就可以这样写
cp ./test.php /var/www/htdocs/
看见了,就这么简单。具体例子可以参考
例子
好了,写完
citb
文件后,接下来就执行打包命令了
rpm_create
[-citb] xxx.citb
打包完成后,包自动放到与
citb
同级目录下,
-citb
参数可以省略,
rpm_create
一样支持
spec
打包方式,也可以
rpm_create –spec xxx.spec
打包
spec
格式文件。
rpm_create
还有如下特点如下
* 打包命令简单,所需要操作就是指定要打包的 citb 文件。
* 目录随意, citb 可以放置在任意目录内。
* 打包后的文件,放在和 citb 同级目录内。
* 相对于 spec ,更简单的 citb 格式文件编写。只要您会写 shell ,就会写 citb 文件。
* 支持多个 citb 文件同时打包 rpm *.citb 。
* 支持 spec 格式文件打包。
* 项目开源,可以随意修改使用。
* 支持 32-64 系统(已经经过测试)
其实 rpm_create 并没有多高深技术原理在里面,其实我也是在 checkinstall 之上做的封装。简单的说,我修改了原 checkinstall 脚本,为 checkinstall 脚本增加了解析 citb 文件的格式,这个 checkinstall 就可以解析 citb 格式文件中的 Name , Version , Release 等信息,然后 checkinstall 把 citb 格式文件最终转化为 spec 格式文件,然后调用 rpmbuild 进行打包操作,打包完成后,把 rpm 包拷贝到 citb 格式目录,而 rpm_create 的作用,就是实现检测 citb 的后缀格式是否正确,用来支持同时打多个包操作,我们用一幅图描述上面的关系
rpm_create 来打包原理和 rpmbuild 打包原理是不同的。使用 rpmbuild 打包时,可以直接打源代码包,而 rpm_create 不能打;也就是说 rpm_create 打包时,需要指定源到目的关系,这时候的源是必须存在的文件,而不能是编译后产生的。比如说我们打包一个 C/C++ 语言编写的包。
使用 rpmbuild 打包时,我们可以在 spec 指定编译操作,然后把编译后的 .so 文件拷贝到指定目录下,来完成打包。而使用 rpm_create ,您需要自己先手工完成 C/C++ 语言的编译工作,产生 .so 文件,然后在 citb 文件中指定这种对应关系。根据我们的经验,这种源代码类型的包,在企业中应用场景比较少的,企业对源代码的管理,基本都是通过 SVN 来管理,真正在生产环境部署时,还是以直接的二进制包为主。对于像 php 这种语言的包来说,根本就无需编译过程的,所以也是不需要编译的,所以这个问题对 rpm 打包并不会有太大影响,但是如果确实需要打源代码包,那么需要您写 spec 文件了。
我们在扩展 rpm_create 时,还需要满足另外一种需求。我们在开发环境下开发完成,并打包后,然后把这个包部署到测试环境上进行测试,测试没有问题后,直接上生产环境,在开发,测试,生产环境上的包应该是一致的。这里就有一个问题,如果我们的产品有连接数据库等设置,那么我们在不同的环境下安装完成包后,需要修改配置文件,更改不同的数据库连接主机,部署包后,直接修改配置文件,这是很危险的操作,有可能造成修改错误,影响产品发布。而在整个打包过程只有开发人员熟悉自己代码结构,了解在开发,测试,生产数据库的 host ,如果开发人员不在的话, appops 就不会修改配置文件,所以这些都是很危险的,为此我为 citb 新增 3 个节点, dev,tst,prd
# dev 环境下执行的 shell 命令
dev:
# echo "dev"
# tst 环境下执行的 shell 命令
tst:
# echo "tst"
# prd 环境下执行的 shell 命令
prd:
# echo "prd"
dev-
表示在开发环境下,执行的
shell
命令,同理
tst
是测试环境,
prd
是生产环境。当然,
rpm
包本身是没有方法可以判断一台服务器是开发,还是测试的。所以,我们的办法是创建
/var/tpm/create/tpm
文件,如果在开发服务器创建,就在里面写
dev
,同理在测试服务器上就写
tst
,生产服务器上写
prd
,按照这样的约定,只需要我们在打包的过程,在
citb
的相关节点上写明在不同环境下的操作,那么安装这个包时,我们就无需手工更改配置文件了。这种方式,也可以通过
spec
方式来支持,如果感兴趣可以联系我。
rpm_create
开源链接
https://code.google.com/p/rpmcreate
rpm
包直接下载
https://code.google.com/p/rpmcreate/downloads/list
相关资料链接:
checkinstall
https://asic-linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz
rpm_create
地址
https://code.google.com/p/rpmcreate
。
最后更新:2017-04-02 04:01:44