共计 3093 个字符,预计需要花费 8 分钟才能阅读完成。
一、部署环境
机器:一台 Linux 虚机,内存 1G,操作系统 CentOS release 5.6,硬盘 100G。
实验应用:乐学方舟后台部署(非正式环境)
应用环境:apache-tomcat-7.0.27,JDK
二、环境搭建
1、下载 hudson,安装部署 http://hudson-ci.org/
点击下载
2、下载完成,需找一台 linux 的机器,上传文件。后台解压运行
# java -jar hudson-3.0.1.war –httpPort=8888&
在实验环境中,hudson-3.0.1.war 会默认解压到 /root/.hudson/ 目录下面,这个改变不了
通过浏览器访问 http://IP:8888/
页面最后 install,等待安装完成 , 安装最新版的 hudson,还是老实的等待安装吧,没有安装后面有的苦了。。
以上是安装 hudson 的过程
三、新建、部署项目
1、新建项目
2、调整系统设置
设置 JDK 环境变量
安装 ant,添加环境变量:http://ant.apache.org/bindownload.cgi 下载安装包,接解压到自定义目录,就可以使用
SVN 的账号密码和添加邮件
可以先测试,其他不变,点击“save”保存
3、开始配置新建的任务
4、配置任务的环境
SVN 路径
Ant 的 build 项目,这个 build.xml 后面说明,很重要的一个文件,贯穿整个 hudson 是否成功完成部署的关键
以上配置好了就可以点击最底下的保存
5、开始构建项目
点击开始构建
点击 console 可以查看够构建项目的过程,也能在这里里面看到是够构建成功,还有报错信息
四、项目构建步骤分析
1、构建项目第一步,通过 ant,build 项目
在项目设置中,配置选项,build 项目
/home/zhengtingting/project/trunk/BackOfficePortal/build.xml 这个我是从 SVN 上面取的源码(还没有编译)文件存放路径
然后一起查看 build.xml 文件,在上文中提到该文件的重要性,现在开始解读改文件
从 SVN 上面取到的源码包存放路径。
这个 build 文件是开发会自带的文件,只要我们取下来,几乎不要变动
最重要的应该是后面的
2、构建项目第二步:停止 tomcat
在 build 文件中可以看到这样的一个节点
在项目中的设置中也能看到这个 build 文件的提到停止 tomcat,由于使用本人自己的用户,所以在脚本中添加了 sudo,但是很悲催的告诉大家,hudson 中不识别 sudo 这个命令
#vi tomcat_stop01.sh
和开心,看到 build 成功了,但是各位亲们,遗憾的是,在实验机器上面看不到 tomcat 停止了,所以吧去掉 sudo 命令,后面你又得很悲催的发现在重新 build 不成功,为什么?嘿嘿,这就是停止脚本的权限了,给个可执行的权限吧。这回成功了。
3、构建项目第三步:备份项目
项目设置中添加一条 ant 节点备份脚本,
重新构建项目吧,这回很确定的说不成功。为什么,还不是文件夹的权限。
首先,备份文件夹的权限,改成所属人为本人,还有项目也是,但是还是失败,最终一狠心,改成 777 的权限,成功了,这个是弊端啊。
4、构建项目第四步:覆盖应用
在 build 成功之后就会在 /home/zhengtingting/project/trunk/BackOfficePortal 目录下面生产应用目录,直接就可以拿去覆盖现有应用就可以了
5、构建项目第五步:启动 tomcat
剩下的也就差不多了,该给的权限都给了,不该给的权限也给了,这回也就成功了
五、hudson 利弊
Hudson | 优势 | 劣势 |
1、部署简单,脚本使用方便 2、构建过程简单 3、页面配置,实施方便,简单 4、可移植性强,主要移动脚本 5、部署项目失败,回滚简单 6、批量部署简单 7、不需要数据库参与 8、集成 RSS/E-mail/IM- 通过 RSS 发布构建结果或当构建失败时通过 e -mail 实时通知。9、Hudson 可以通过插件扩展 | 1、安装插件时间长 2、跨机器构建项目需要人工参与 3、文件夹权限不严谨 4、hudson 自动解压目录不合理(/root/.hudson/)5、需要依赖自动化部署的 ant,git 等 6、使用批处理命令直接移 war 包。不过这样的缺点在于,移动失败的时候,会显示批处理命令执行成功,hudson 是不会报错的,需要人工检查。 |
六、环境部署和实际应用
1、初始环境的搭建和应用部署
有我们 OPS 有自己编译好的 yum 源,可以直接将构建项目过程中的第二步停止应用脚本改成 yum 安装包。
A、很多应用都需要添加虚拟主机,这就需要在脚本中匹配到某行,添加虚拟主机的配置
B、构建项目的第二步停止 tomcat 和第三步备份项目可以省略,不过也可以不省略,看个人习惯
C、其余的步骤都是相同的
2、跨机部署构建项目
跨机器或是双机部署应用的情况下,这边采用的是 rsync 同步的方式,部署应用,在这之前是需要人工手动的进行操作,进行配置 rsync(rsync 部署安晓会他们已经试验过了,有什么需要的这个也是可以沟通滴)
rsync -vazP –delete ip::war/ /home/zhengtingting/deploy/ >>/home/zhengtingting/rsync.log 2>&1
Hudson 如果不需要手工参与的话,需要使用一个插件,系统管理 / 插件管理 / 可选插件,系统列出可用的所有插件,找到 Deploy 插件选中并点击安装按钮,等安装完毕后重启 tomcat,就可以看到 Deploy 插件已经安装好。不过在 hudson-3.0.1 的就没有看到了。安装的插件也没有看到这个功能。
重新打开上面添加任务的配置界面,找到配置文件的最后,找到 Post-build Actions(构建后的动作)
不过这个构建有点不好的一个现象,不过是否成功的覆盖移植应用,最终在 build 都会显示成功,如果失败就需要手工的参与,批量处理的这种最好是先在一天验证是否通过后在进行批量的处理。
3、通用性
A、脚本移植
Hudson 可移植性还是挺好的,不过在移植过程中,需要重新的下载和更新 hudson,需要占用大量的时间。里面的插件,至少需要 2 - 3 个小时的安装时间,不过在这个时间可以迁移脚本就行了。安装好插件,需要的配置也得需要个半个小时至 1 个小时时间。Hudson 可移植的也就是脚本,就依赖的包,不需要什么东西。移植性还是相对不错的。
B、没有数据库参数
Hudson 不需要涉及到任何数据库参与部署,这就可以避免了很大部分的数据库的更改,还有就是匹配
4、硬件管理
Hudson 到使用到现在还没有看到有硬件管理方面的插件。
5、依赖和回滚
A、依赖
Hudson 部署看个人喜好用 ant,git,maven 都行,不过还是需要从 SVN 上面下东西,
本来从开始就使用 ant,必须一定要安装一个,不然是不会成功滴。还有安装的时候需要的各种插件,SVN,EMAIL, 还有几个页面初始打开的是必须要安装的几个插件,否则,是会失败滴。
B、回滚
项目构建失败的回滚,只是更改下脚本,将原本备份的解压覆盖到应用目录中就行,最开始的停止 tomcat 和最后的启动 tomcat 都需要留着,不需要改动。
七、综上所述
Hudson 使用还是挺便捷的,也有所利弊,不过应用在新的简单的项目上面是可以的,本次实验是在本机传输的,后期会跟进对于跨机器的部署,在这边是考虑使用 rsync 同步的,测试那边已经在使用这个工具跨机器使用。
本文永久更新链接地址 :http://www.linuxidc.com/Linux/2017-03/141673.htm
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)