内容提要
Jenkins + Git + Maven + tomcat集成环境部署，实现自动构建、部署web应用
环境依赖
OS：Centos 6.5
JDK：1.7.x
Maven：3.1.x
Git： 1.7.1，自建GitLab平台
tomcat：7.x
Host：
master：194
slave： 198
（静态IP统一定义为内网24位子网掩码，配置双机互信，首次验证，需人为操作）
步骤说明
上述环境依赖宿主机上均需安装
· JDK安装，安装后之后，请注意配置JAVA_HOME环境变量。
·Maven安装：从apache下载tar.gz压缩包，在合适的目录下解压即可。此后配置全局环境变量。
·tomcat安装：不做详细阐述
·Git：节省实验时间，直接执行“yum install git”
若贵司GitLab是自建的内网平台，不要忘机在宿主机上添加hosts解析
Jenkins 配置
· Jenkins jar包下载
· 将jenkins.war通过tomcat部署
使用tomcat挂在启动jenkins服务
这样我们可以非常简单的修改一些配置参数和维护
启动jenkins服务的方式还可以通过jar方式启动
· 修改context.xml文件，增加jenkins环境变量，由tomcat挂载。
<Context>
<Environment name="JENKINS_HOME" value="/home/jenkins_home/" type="java.lang.String"/>
</Context>
· 修改tomcat-users.xml，配置jenkins的用户，此后用户可以在jenkins的页面上登录和授权操作
拓展：
关于jenkins的用户授权，官方提供了很多方式，比如LDAP、基于数据库等等。本实例基于tomcat user的方式，简单易用。
<tomcat-users>
<role rolename="admin"/>
<user username="admin" password="admin" roles="admin"/>
<user username="developer" password="developer" roles="manager"/>
</tomcat-users>
admin可以对系统各项配置进行修改，manager可以管理项目、部署等
· 将jenkins.war放置在webapps目录下
我希望jenkins作为ROOT项目加载
所以删除原有的ROOT项目，并将jenkins.war重命名位ROOT.war
这样在通过http访问jenkins时，不需要加ContextPath了
· 启动jenkins tomcat，并通过web访问。
./startup.sh
访问http://*.*.*.194:$PORT，然后使用admin用户登录
· Master 配置
1、插件管理
在“可选插件”中，需要几个常用的插件
主要涉及到：
SSH
Git
GitLab
Maven
Deploy插件（我们可以在maven build之后，立即将war发布到web容器中，而不需要手动操作或者写shell脚本来copy文件）
管理员可按需安装，安装完成之后，重启Jenkins
2、系统配置
其中重要的2个选项：JDK，Maven
我们需要告知master它们安装在何处
3、Build与发布
Deploy插件是通过外部（http）方式“deploy/redeploy”
所以需要在tomcat上进行用户授权
编辑tomcat-users.xml，增加如下配置：
<tomcat-users>
<role rolename="manager"/>
<role rolename="admin"/>
<user username="deployer" password="deployer" roles="standard,manager,admin,manager-script" />
</tomcat-users>
增加一个“deployer”用户，我们可以通过tomcat manager机制来部署war
master需要ssh访问slave机器（部署、启动，发送文件等）
所以在开始之前，需要在“jenkins”-->“Credentials”-->“Add Credentials”添加一个SSH验证规则
同时创建一个Global范围的SSH无密码登陆
此外，我们还需要在GitLab中目标项目中增加“deploy key”
在创建item时，还需要指定，这个item的job运行结果最终保存在哪个“节点”上，即最终发布的位置
指定Git库的地址，并配置master与GitLab通讯的SSH验证机制
当代码从Git下载之后，启动Maven build阶段
在Maven build时，我们指定“Goals”，这个很重要，否则就没有意义了
值得注意的是：
在发布之前，需要先删除web应用的tomcat中原有的ROOT.war，才能触发tomcat undeploy操作。
这或许是“Deploy plugin”的bug，如果ROOT.war已经存在，则无法再次deploy/redeploy
· Slave 配置
值得注意的一点是：
jenkins的slave不需要像master一样部署在tomcat上。
master将会通过ssh将slave.jar文件到slave节点上，并启动slave。
通过导航：“系统管理”-->“节点管理”-->“新建节点”，来增加slave。
此后需要部署在slave上的web应用，只需要在创建item时指定“Restrict where project can be run”为slave即可。
Q&A
Q:为什么两台机器所需要的环境依赖需要完全一致？
A：因为slave接收master的job调度后，将会使用Git从GitLab上同步代码并使用Maven进行build，这个过程都是在salve的本地进行。
Q：如果部署的时候报错了，那我有哪些思路可以进行排查？
A：1）tomcat是否已经启动。
2）tomcat-users.xml是否配置正确。
3）tomcat的版本和“Deploy plugin”中container指定的是否一致。
4）tomcat下是否已经有ROOT项目，如果有，请删除，然后重启tomcat，此后再使用jenkins发布
