共计 5488 个字符，预计需要花费 14 分钟才能阅读完成。
把 Jenkins + Git + Maven + Tomcat 集成环境搭建起来了，最终主要实现“自动构建、部署”Web 应用。
1、安装环境
操作系统：CentOS 6.5
JDK：1.7.x
Maven：3.1.x
Git：1.7.1，自建 GitLab 平台
tomcat：7.x
上述宿主机器 2 台：192.168.1.194，192，168.1.198，其中 194 位 Jenkins Master，198 位 slave。
2、第三方安装安装和环境配置
JDK、Git、Maven、tomcat 在上述 2 个宿主机器上都需要安装，即 jenkins master 和 slave 都需要这些环境。
1）JDK 安装：略；安装后之后，请注意配置 Java_HOME 环境变量。
2）Maven 安装：从 apache 下载 tar.gz 压缩包，在合适的目录下解压即可。此后配置 M2_HOME 环境变量。
3）tomcat 安装：略。
4）Git：安装非常简单，直接执行“yum install git”即可。
5）如果你的 GitLab 是自建的内网平台，千万不要忘了在上述 2 个宿主机器上增加 hosts 解析，例如：
Java 代码
192.168.1.110 git.xxx.com
上述环境安装，需要在 Jenkins 和 slave 上都进行，即 slave 上也需要 JDK、Maven、Git，因为 slave 接收 master 的 job 调度后，将会使用 Git 从 GitLab 上同步代码并使用 Maven 进行 build，这个过程都是在 salve 的本地进行。
此外，两个宿主机器，还需要安装 ssh-keygen 等必要软件，同时它们还需要交换 public Key，确保 2 个机器能够实现“无密码登陆”（过程略）。因为 Jenkins 在 ssh 传输时无法绕过“授权确认”的手动操作，所以管理员需要人为的进行一次 ssh 登陆。
3、jenkins master
master 是 job 调度的分配者，我们需要首先安装部署它。从“https://jenkins-ci.org/”官网下载 jenkins.war 部署包，我们将 jenkins.war 通过 tomcat 部署，即使用 tomcat 挂在启动 jenkins 服务，因为这样我们可以非常简单的修改一些配置参数和维护。（启动 jenkins 服务的方式还可以通过 jar 方式启动，请参见其他说明文档）
将 master 安装在 192.168.1.194 机器上，单独安装一个 tomcat，其 http 端口为 38080。并修改如下文件：
1）context.xml：增加 jenkins 环境变量，由 tomcat 挂载。
Java 代码
<Context>
….
<Environment name=“JENKINS_HOME” value=“/home/jenkins_home/” type=“java.lang.String”/>
</Context>
“JENKINS_HOME”是 jenkins 的 home 目录，通常设定为“磁盘空间较大”的分区，这个目录中将放置 maven build 的文件，历史部署记录等等，所以将会消耗很大的存储空间。
2）tomcat-users.xml：配置 jenkins 的用户，此后用户可以在 jenkins 的页面上登录和授权操作，对于 jenkins 的用户授权，官方提供了很多方式，比如 LDAP、基于数据库等等。本实例基于 tomcat user 的方式，简单易用。
Java 代码
<tomcat-users>
<role rolename=“admin”/>
<user username=“admin” password=“admin” roles=“admin”/>
<user username=“developer” password=“developer” roles=“manager”/>
</tomcat-users>
添加 2 个管理员用户，其中 admin 可以对系统各项配置进行修改，manager 可以管理项目、部署等。
3）将 jenkins.war 放置在 webapps 目录下，我们此处希望 jenkins 作为 ROOT 项目加载，所以删除原有的 ROOT 项目，并将 jenkins.war 重命名位 ROOT.war，这样在通过 http 访问 jenkins 时，不需要加 ContextPath 了。
4）启动 jenkins tomcat：./startup.sh
5）访问“http://192.168.1.194:38080”，然后使用 admin 用户登录（用户密码参见 tomcat-users.xml）。
4、master 配置
如果 master 需要真正的能够运行 job，我们还需要一些周密的配置。
1）插件管理：
jenkins master 需要几个常用的插件，在“可选插件”中，建议将如下列表插件选中并安装：
这些插件主要涉及到：ssh、Git、GitLab、Maven，已经后面我们需要提到的“deploy”插件。管理员可以根据需要选择性的安装需要的 plugins。
安装完之后，重启 jenkins。
5、系统配置
在 jenkins 的“系统管理”–>“系统设置”页面，来设定 master 全局的配置，其中重要的 2 个选项位 JDK 和 Maven，我们需要告知 master 它们安装在何处。
1）JDK：
2）Maven：
6、Build 与发布
我们接下来创建一个 job，这个 job 将从 GitLab 上下载源码到本地，然后使用 Maven build 和打包，并发布到 tomcat 上。这个过程正是我们常用的。
1）“Deploy to container plugin”：这个插件我们在上述已经看到，如果还没有安装，请首先安装；它主要用来将“war”文件“deploy/redeploy”到 web 容器中，比如 tomcat、jboss 等。有了这个插件，我们可以在 maven build 之后，立即将 war 发布到 tomcat 中，而不需要手动操作或者写 shell 脚本来 copy 文件。
首先，我们需要准备一个 tomcat，用来部署我们的 web application，过程略。此 tomcat 的端口为 8080，部署在 master 宿主机器上。
因为 Deploy 插件是通过外部（http）方式“deploy/redeploy”，所以需要在 tomcat 上进行用户授权。编辑 tomcat-users.xml，增加如下配置：
Java 代码
<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。参见稍后讲解。
2）新建 Item：
授权与验证：master 需要 ssh 访问 slave 机器（部署、启动，发送文件等），以及从 git 上下载代码，所以我们在开始之前，需要指定这些。“jenkins”–>“Credentials”–>“Add Credentials”添加一个 SSH 验证规则：
我们创建一个 Global 范围的 SSH 无密码登陆，这个可以在此后 master 与 slave 通讯有用。前提是 master 与 slave 已经交换了 public key。“From the Jenkins master ~/.ssh”即使用 master 宿主机器“~/.ssh”目录下的公私钥。
然后，我们“新建”：
因为我们是基于 Maven 构建项目，所以选择第二项，如果你已经创建过类似的 item，可以选择“复制已有的 item”，输入 item 的名字，那么它相应的配置就会导入，就像模板一样，我们无需每次都重复填写配置表单。
在创建 item 时，我们还需要指定，这个 item 的 job 运行结果最终保存在哪个“节点”上，例如 web 项目最终发布在哪个 server 上，在 jenkins 中，master 和 slaver 都称为“节点”。
指定 Git 库的地址，并配置 master 与 GitLab 通讯的 SSH 验证机制：
因为 master、slave 均需要使用 Git 从远端下载代码，在这个模块中，“Credentials”选择刚才我们添加的“root”，这样 jenkins 使用 Git 下载代码时将会把 SSH 的秘钥发过去。此外，我们还需要在 GitLab 中目标项目中增加“deploy key”：
我们将 master、slave 两个机器的 public key 添加到 GitLab 项目的“deploy key”中。如果你的 item 无法正确访问 Git，比如“验证被拒绝”，你应该尝试通过 shell 登录到 master、slave 机器上，使用 git 命令尝试下载项目代码，可能因为 jenkins 无法跳过 ssh 的“授权确认”导致。
当代码从 Git 下载之后，启动 Maven build 阶段：
在“Pre step”中，我们增加了一小段 shell，主要作用就是在发布之前，先删除 web 应用的 tomcat 中原有的 ROOT.war（在某些版本的 tomcat，还需要增加一行“rm -r -f ROOT”，即将原有项目的所有文件删除，才能触发 tomcat undeploy 操作），这或许是“Deploy plugin”的 bug，如果 ROOT.war 已经存在，则无法再次 deploy/redeploy。
在 Maven build 时，我们指定“Goals”，这个很重要，否则 Maven build 就没有意义了。“Goals and options”根据个人项目的情况来定义，选择合适的 profile 环境。
下面我们介绍“Deploy plugin”，这个插件就是将 Maven 打包生成的 war，发布到指定的 tomcat 下。很好的一个插件。
其中“WAR/EAR files”选项指定 war 的位置，这个路径是个相对路径，相对于“/home/jenkins_home/workspace/{你的 item 名称}”，本实例是一个 maven 多模块项目，且每个 module 打包的名称都为 ROOT.war，这样方便部署。请管理员指定正确的路径。
Containers 中，我们使用了 tomcat 7，输入上文我们设定的用户名和密码，指定 tomcat Url，需要注意，既然应用是基于 http manager 的方式 deploy，那么此 tomcat 的 webapps 自带的“manager”项目不能被删除，同时 tomcat 还需要处于启动状态。（tomcat 也可能以为死亡，所以建议在 pre step 中加上对 tomcat 状态的判断，如果 tomcat 死亡，先执行 startup.sh）。
如果在部署时，报错。请按照如下方式排查：
1）tomcat 是否已经启动。
2）tomcat-users.xml 是否配置正确。
3）tomcat 的版本和“Deploy plugin”中 container 指定的是否一致。
4）tomcat 下是否已经有 ROOT 项目，如果有，请删除，然后重启 tomcat，此后再使用 jenkins 发布，因为 reploy 时会检测旧的 ROOT 和新的 ROOT.war 项目的版本相容性，如果不同，则会导致 reploy 失败。
到此为止，第一个 item 配置完毕，保存后即可通过“立即构建”来部署我们的项目了。
7、Slave 节点
通过上文，我们已经在 Slave 机器上安装好了 SSH、Git、Maven、JDK 等，同时我们也需要在 Slave 节点安装一个 tomcat，用来部署 web application。
需要注意的是，jenkins 的 slave 不需要像 master 一样部署在 tomcat 上，我们只需要在 jenkins 的页面上操作即可，master 将会通过 ssh 将 slave.jar 文件到 slave 节点上，并启动 slave。
通过导航：“系统管理”–>“节点管理”–>“新建节点”，来增加 slave。其实此时我们已经看到“master”节点已经被默认添加进来了。
保存后，会提示你“启动 slave”，你可以根据需要是否启动 slave。
此后那些需要部署在 slave 宿主机器上的 web 应用，只需要在创建 item 时指定“Restrict where project can be run”为 slave 即可。
—END—
other: profile
各属性节点的值，用占位符 ”${属性名}“ 占位，maven 在 compile/package 时，会根据 profile 的环境自动替换这些占位符为实际属性值。
默认情况下：
maven package
将采用默认激活的 profile 环境来打包，也可以手动指定环境，比如：
maven package -P dev
将自动打包成 dev 环境的部署包 (注：参数 P 为大写)
gitlab/github 可以添加 Webhooks 实现自动部署
如果是 springboot 项目，则配置更简单
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-08/146629.htm
