集成部署流程
![]()
执行部署脚本时:
![]()
文档流程
![]()
执行部署脚本时:
(1) 如果(/tmp/deploy.lock锁文件)存在,则说明有部署程序在运行,此时不能进行本次部署=====>echo返回"Deply id running" 并退出本次部署程序
(2) 如果(/tmp/deploy.lock锁文件)不存在,则说没有部署程序在运行,则此时可以进行部署:
<1> 传入参数是deploy ,则说明要进行新代码部署,则进行如下操作:
1>执行shell_lock函数: 加上锁 ---> touch生成/tmp/deploy.lock锁文件
2>执行code_get函数: 获取代码和版本号
1. 正常应该从git获取, 而这里为了演示(直接复制/deploy/code/web-demo/项目代码文件夹到/deploy/tmp/这个待部署临时目录)
2. 将本次git pull到项目的版本号保存到一个变量中, 这里由于没有git所以直接指定版本是456, 存入变量 API_VER=456
3. 写入日志(年月日时分秒执行了code_get操作)
3>执行code_build函数: 将代码编译
1. 用于Java等需要编译的语言代码,而这里是演示则省略编译过程, /直接跳过进行后续操作
2. 写入日志(年月日时分秒执行了code_build操作)
4>执行code_config函数: 获取项目通用配置文件 并将项目通用配置文件目录改名为"项目名+版本号+时间"
1. 这里演示则将配置文件从/deploy/config/web-demo/base/这个web-demo项目的通用配置文件目录复制到/deploy/tmp/web-demo/目录,
2. 将这里包含项目代码和通用配置文件的web-demo文件夹改名为"项目+版本号+当前时间"(web-demo-234-2016-12-23-09-23-11)
3. 写入日志(年月日时分秒执行了code_config操作)
5>执行code_tar函数: 将待部署的代码和配置文件的项目文件夹打包
1. 切换到/deploy/tmp目录,使用tar命令将本次部署文件夹web-demo-234-2016-12-23-09-23-11打包成为web-demo-234-2016-12-23-09-23-11.tar.gz
2. 写入日志(年月日时分秒执行了code_tar操作,打包后的待部署项目压缩文件是web-demo-234-2016-12-23-09-23-11.tar.gz)
6>执行code_scp函数: 将待部署项目压缩包发送到各个部署节点的项目部署目录
1. 这里演示,首先通过for循环遍历"待部署的预生产测试node节点列表",使用scp命令将待部署项目压缩包web-demo-234-2016-12-23-09-23-11.tar.gz发送到各个预生产测试节点的项目部署目录(/opt/webroot/)
2. 再接着通过for循环遍历"待部署的生产node节点列表",使用scp命令将待部署项目压缩包web-demo-234-2016-12-23-09-23-11.tar.gz发送到各个生产节点的项目部署目录(/opt/webroot/)
3. 写入日志(年月日时分秒执行了code_scp操作)
7>执行pre_deploy函数: 在预生产节点部署
1. 将预生产测试组节点机从集群中移除出来,(这里演示,跳过,直接将"remove from cluster"写入日志)
2. 到每台测试节点的项目目录中对新scp来的部署压缩包解压缩, (for循环测试节点列表,用ssh连接登录每台测试节点,并切换到项目部署目录(/opt/webroot/),用tar命令解包)
3. 然后删除项目上个版本的"真实项目目录"(rm -f /webroot/web-demo), 并从新将"新部署项目目录的下的新解包目录"软链接到"真实项目目录" (ln -s /opt/webroot/web-demo-234-2016-12-23-09-23-11 /webroot/web-demo)
4. 写入日志(年月日时分秒执行了pre_deploy操作)
8>执行pre_test函数: 预生产节点部署完成的测试,测试成功后添加回生产集群
1.这里演示网页部署,所以可以使用wget等从测试几点获取最新网页代码测试,测试成功后,将测试节点重新加入生产集群(这里不便演示,直接echo输出"add to cluster")
2.写入日志(年月日时分秒执行了pre_test操作)
9>执行group1_deploy函数: 将第一组生产节点从集群移出,并进行部署
1.移出集群操作,不便演示,直接用echo输出"group1 remove from cluster"
2.for循环遍历该生产组的每台节点,依次部署: 这里用ssh登录每台节点,重复预生产节点的部署操作(切换部署目录-->解包-->删除真实项目目录-->重新将(新解压项目目录与真实生产目录)创建软连接)
3.注意,还需要将那些需要额外部署的节点,单独列出来单独部署(即/deploy/config/web-demo/other/下的特殊文件)
4.写入日志(年月日时分秒执行了group1_deploy操作)
10>执行group1_test函数: 第一组生产节点部署完的测试,测试成功后添加回生产集群
1.这里演示网页部署,所以可以使用wget等从测试几点获取最新网页代码测试,测试成功后,将group1节点重新加入生产集群(这里不便演示,直接echo输出"add to cluster")
2.写入日志(年月日时分秒执行了group1_test操作)
11>后续应该重复9/10步骤,部署其他节点组,这里不再赘述,直接省略
12>执行shell_unlock函数: 去掉锁 ---> rm 去掉/tmp/deploy.lock锁
<2> 传入参数是rollback ,则说明要进行代码回滚,则进行如下操作:
1>执行shell_lock函数: 加上锁 ---> touch生成/tmp/deploy.lock锁文件
2>执行rollback()函数: 指定回滚到那个项目 ---> 回滚操作需要传入一个回滚版本参数
如果用户没有输入回滚版本参数,则提示用户输入回滚版本,并执行unlock函数解锁,并退出本次回滚操作;
如果用户输入的参数是"list",则为用户列出当前可以回滚的所有版本信息
如果用户输入的参数是真实回滚版本,则执行rollback_fun函数:遍历"待回滚节点列表",将其生产项目的软连接更改到指定回滚版本的目录
<3> 传入参数是其他 ,则执行usage函数:
提示用户正确使用该"部署/回滚"脚本的方法
文档流程:
1.部署脚本编写与测试 ---> deploy.sh [1.11部署机上]
2.安装Gitlab私有代码管理仓库 -->将gitlab由域名解析改为IP解析 -->关闭用户注册功能(私有仓库) -->创建用户组 -->在用户组中创建项目 -->配置[部署机www用户有权限来pull/push该项目] -->测试效果
3.安装Jenkins持续集成工具 -->创建admin用户 -->登录管理页面
4.在Jenkins中安装gitlab插件(GitlabPlugin)并配置Jenkins以[部署机root用户]身份上gitlab拉取项目代码权限
1> 将部署机root用户的公钥发给gitlab -->gitlab将其新增到Deploy-Key中配置成部署公钥
2> 将部署机root用户的私钥发给Jenkins -->Jenkins创建一张(通过用户名/私钥ssh验证的)新证书
5.在Jenkins中创建新任务来测试从gitlab拉取代码功能
1>新建任务(如auto-test)并设置其从gitlab拉取源码-->在该任务配置的"源码管理"选项中 -->选择从git拉取源码(填写项目git地址/拉取分支/拉取代码的验证证书(上步创建的))
2>立即构建该任务测试从gitlab拉取代码 -->拉取代码成功,将代码存放在Jenkins后端的workspace目录中,在其下的auto-test目录就是该项目的代码,可在其中执行"git show"命令查看该项目上次拉取情况
6.安装Sonar代码质量管理平台 -->以admin用户登录管理页面
1>在sonar中安装中文支持插件 -->重启sonar后管理界面显示为中文
2>在sonar中安装要被分析的语言包(如java python php js) -->重启sonar后可以对这些用这些语言编写的项目代码进行语法勘误
7.安装SonarQube Scanner扫描器 -->Sonar进行编程语言语法勘误使用的是这个扫描器完成的
1>配置SonarQube Scanner与Sonar关联 -->在SonarQube Scanner的配置文件中指明(sonar所在主机IP/sonar所在数据库位置+登录用户+数据库密码/sonar要分析代码的编码字符集)
2>要用SonarQube Scanner对项目代码勘误,必须要有一个配置文件指明(项目代码路径/项目语言/编码字符集)等信息,这个配置文件可以由开发人员附加在项目代码中,也可在Jenkins中编写该项目的这个配置文件
3>启动SonarQube Scanner测试其代码检测功能 -->在sonar管理界面中显示会显示被分析的项目名,点击该"项目名"就可查看其详细代码勘误情况
8.配置Jenkins与Sonar结合
1>Jenkins安装SonarQubePlugin插件 -->在"系统配置"中添加上该插件,并指明Sonar所在主机的IP
2>Jenkins添加SonarScanner工具 -->在"全局工具配置"中添加已安装到(与Jenkins同一主机)的SonarQube Scanner -->指明SonarQube Scanner启动路径即可
3>测试Jenkins与Sonar的结合效果
1.给上述可以从gitlab拉取代码功能的auto-test任务,再增加一个构建步骤--执行"SonarQube Scanner代码检测" <--如项目中没有Scanner的检测配置文件,则需要在这里新增Scanner的检测属性(Key/Name/Source/Language/Encoding等)
2.对auto-test任务,点击"立即构建"则: 从git拉取代码 -->使用SonarQube Scanner对项目代码进行勘误检测质量分析 -->点击任务名"auto-test"按钮跳转Sonar页面展示最近构建的代码分析结果
3.还可以对被Sonar分析的项目添加"仪表项",通过dashboard方式更好展示代码分析结果
说明:持续集成---到此步就由开发人员查看代码检测结果,如果不合格继续修改,继续提交,如此不断往复 ===>持续集成
9.设置Jenkins任务构建后操作
1>构建后进行代码发布
2>构建不成功发送邮件给指定人
3>构建成功后提交到gitlab等等
10.在Jenkins中可以将上述auto-test任务名进行更改
11.在Jenkins中新建demo-deploy任务--负责到部署机执行部署脚本(deploy.sh)
1>新建demo-deploy任务
2>给该demo-deploy任务添加构建步骤---选择执行Shell命令 -->填写shell命令 "sudo ssh www@192.168.1.111 './deploy.sh' "
3>配置本机Jenkins用户拥有sudo到root执行ssh命令的权限 --> vim /etc/sudoers --> "jenkins ALL=(ALL) NOPASSWD: /usr/bin/ssh"
4>配置本机root用户无密码以部署机的www用户登录部署机 --> 把本机root用户的公钥发送填写到www用户的authorize.keys文件中
5>测试构建该demo-deploy任务成功 -->成功sudo为root并以www用户身份连接到部署机执行deploy.sh这个部署脚本,完成代码拉取--部署到测试环境--测试--部署到真实生产区组
12.在Jenkins中安装Parameterized Trigger Plugin触发器插件 ---让一个构建任务执行完毕后可以出发执行下一个构建任务,这里让auto-test任务执行完毕后触发继续执行demo-deploy任务,实现:代码拉取-->测试-->部署 一条龙
1>Jenkins安装Parameterized Trigger Plugin插件
2>配置auto-test任务-->给其增加一个"构建后操作"--即,继续构建demo-deploy任务
3>测试: 点击构建auto-test任务 -->后续demo-deploy任务也被构建
13.在Jenkins中安装Build Pipeline plugin插件 ---流水线展示任务的构建过程
1>安装Build Pipeline Plugin插件并重启Jenkins
2>新建一个pipeline视图 -->给视图自定义命名 -->指定该视图对应的任务(如auto-test) -->并设置视图显示参数(如显示近5次构建/显示名称头部/每3秒刷新一次/显示lightbox类型样式)
3>测试:重新构建auto-test任务,则以图形方式看到整个任务的构建过程(auto-test --> demo-deploy)
14.在Jenkins中安装Gitlab Hook Plugin插件 ---监测gitlab项目变化 -->可以设置一旦监测到gitlab指定项目出现提交事件,就立即重新构建其对应的某个任务
1>安装Gitlab Hook Plugin插件
2>安装Build Authorization Token Root Plugin插件 --设置gitlab与Jenkins之间的令牌认证
3>设置gitlab与Jenkins之间的令牌认证
1.生成令牌: "openssl rand -hex 10" 随机生成一个10个字符的字符串作为Token令牌
2.给Jenkins中对应的任务增加一个"远程构建任务触发器" -->给auto-test任务的配置中添加一个"构建触发器" <--设置Token为上述字符串/选择gitlab有新提交时触发
3.在gitlab中对应项目中添加一个Webhooks钩子脚本 -->auto-test -->http://(Jenkins的地址)**job=(要触发的构建任务如auto-test)&token=(上述token)
4.测试:在本地web-demo项目中稍作更改并push提交gitlab -->触发auto-test任务执行 -->随后demo-deploy也被触发执行