Jenkins是什么？

一款Java平台的开源持续集成（Continuous Integration，CI）引擎。主要用于持续集成，增加开发效率。官网地址: Jenkins官网

如我们当前应用最多的场景就是：一个项目我们边做，但是呢测试也在边调试，而我们不可能每一次提交代码就为测试重新打包一份最新的代码让他们去测试，这时候持续集成就能帮我们解决这个问题，我们可以在jenkins里面去解决这个问题。

当然，我们还可以在jenkins里面设置每当项目仓库改变，jenkins就去拉取最新代码并构建。

持续部署/CI/CD/DevOps

| 持续部署（continuous deployment）: 通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。
| 持续集成(Continuous integration)：一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

CI仅仅是一个开发构建过程，都在开发端，是实现敏捷开发的一种方式，研发过程自动化
| 持续交付（Continuous delivery）:一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
| DevOps : 一种方法论，是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。

CD跟当前很火的DevOps很容易混淆，但它们是不同的两个概念，这里要简单说明一下：

DevOps的范围更广，涉及多个团队之间的合作（开发、运维、测试、管理部门等），目的是将软件交付的过程自动化。CD（持续交付）只是自动化交付的一种手段，关注点主要在于将不同的过程集中起来，更快、更频繁的执行这些过程。

这里有个误区：

很多公司在实施容器云时实现CI（Continuous Integration，持续集成），或者CI/CD（Continuous Integration/Continuous Delivery or Deployment，持续集成/持续交付 or 持续部署）就叫DevOps。我觉得这只是实现DevOps的一部分，但不等于DevOps。

但CI/CD依然没有解决开发、运维、质量保证部门之间的协作和整合。职责依然没有划分清楚，不足以支撑企业生产环境部署要求。

安装

网上资料一大把，这些省略不赘述

Tips: 一般安装在CentOS系统上，可以使用yum方式安装，简单方便如 yum -y install jenkins 可能存在yum源没有jenkins安装包，可自行搜索添加可用yum源。

后面主要以yum安装方式来介绍jenkins相关的内容

访问方式

在浏览器中输入 http://服务器IP地址:8080

默认端口修改有几种方式，根据你安装jenkins方式来选择：

| java命令启动 java -jar jenkins.war –httpPort=9090
| tomcat启动将jenkins.war放到webapps，修改tomcatserver.xml内的端口即可
| yum安装方式启动编辑/etc/sysconfig/jenkins，找到JENKINS_PORT配置项，进行修改

修改成功并重启服务后，http://服务器IP地址:修改后端口即可访问

Tips: 修改完端口后，均需要重启服务，yum方式安装的，启动命令：/etc/init.d/jenkins start CentOS7的启动命令有点不一样 systemctl start jenkins

首次安装成功成功看到的界面可能如下：

先科普下一些jenkins中常用的专业词汇

Jenkins专业词汇

| Artifact - 在Build或Pipeline 运行期间生成的不可变文件，该文件归档到Jenkins Master上以供用户随后检索
| Build - 项目单次执行的结果
| Item - 对应于：Folder, Pipeline, or Project
| Job - 一个不推荐的术语，与项目同义
| Node - 节点，作为Jenkins环境的一部分并能够执行Pipeline或项目的机器
| Project - 用户配置的Jenkins应该执行的工作描述，如构建软件等
| Plugin - Jenkins功能扩展
| Workspace - 工作空间

专业词汇还有很多，暂且列出这些，下面安装Jenkins界面逐一给大家介绍

先来看张图，这是目前我们测试团队在用的Jenkins

先介绍下系统管理相关内容

系统管理

主要介绍系统管理中系统设置、全局安全配置、全局工具配置、管理节点等功能

Tips：系统设置里设置的内容存储在config.xml文件（大概解读下这个xml文件）

系统设置

从系统管理->系统设置进入设置页面
系统设置中的几个常规配置项：
- 执行者数量：设置可同时执行的job数，当执行job数达到该值时，其他job将处于等待状态
- 生成前等待时间：构建开始前的等待时间，避免代码未提交完整，导致构建失败
- Jenkins URL：访问Jenkins的地址，如 http://10.200.143.36:8080/
- 系统管理员邮件地址：设置发送通知邮件的地址，例如hzkay@tairanchina.com
- Extended E-mail Notification（需要安装Email Extension Plugin插件）

全局安全配置

jenkins默认设置不做安全检查，任何人都可以修改设置，当在多个团队下使用时，没有安全检查会引起不必要的问题，下面介绍几个常用的jenkins安全设置。

从系统管理->全局安全配置进入设置页面
勾选“启用安全”，如下图：

1）安全域：用于控制用户访问的工具

| Jenkins专有用户数据库：使用Jenkins自己的用户列表验证, 而不是外部系统代理，这适用于没有用户数据库小范围的设定。勾选【允许用户注册】，可通过界面注册成为jenkins用户
| Servlet容器代理：使用Servlet容器认证用户，遵循Servlet规范，Jenkins1.163版本遗留的历史（不推荐使用）

2）授权策略：控制用户执行某些操作的权限

| 任何用户可以做任何事(没有任何限制)：不执行任何授权,任何人都能完全控制jenkins,包括匿名用户
| 安全矩阵：常用的一种授权策略，通过表格控制每个用户的操作权限
| 登录用户可以做任何事：用户在登录成功后，具备jenkins最高权限，匿名用户则只有查看权限
| 遗留模式：适用于Jenkins1.164以前的版本,只有admin有最高权限，其他用户则只有查看权限
| 项目矩阵授权策略：扩展于”安全矩阵”,允许把下面的ACL(访问控制列表)矩阵附加到每个项目定义中(在Job配置页面)，其他配置项保持默认即可

项目矩阵授权策略在工作中用得较多，比如针对不同的项目选择不同的用户具有不同权限。

各种权限如下(在配置页面将鼠标放到该权限上即可查看帮助)：

其中有一些比较特别的权限：

最大的权限是Overall的Administer，拥有该权限可以干任何事情。

最基本的权限是Overall的Read，用户必须赋予阅读的权限，不然什么都看不到。

Job的Discover权限是一个奇葩的权限，帮助说Discover比Read的级别更低。如果匿名用户(没有访问job的权限)直接访问一个Job的Url将重定向到登陆页面。(经测试，这个权限应该是被废弃了。)

Credentials的ManageDomains这个权限没有看懂干嘛的，有懂的大家一起交流哈！

Tips:如果有个用户被赋予了Overall的Read，并没有被赋予Job的Read权限，那么该用户就无法访问job。原因：没有权限。

安全配置在配置文件中config.xml的内容如下：

<useSecurity>true</useSecurity>
<authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">
            <permission>hudson.model.Hudson.Administer:admin</permission>
            <permission>hudson.model.Hudson.Read:anonymous</permission>
            <permission>hudson.model.Item.Build:dev</permission>
            <permission>hudson.model.Item.Read:anonymous</permission>
            <permission>hudson.model.Item.Read:dev</permission>
</authorizationStrategy>
<securityRealm class="hudson.security.HudsonPrivateSecurityRealm">
            <disableSignup>false</disableSignup>
            <enableCaptcha>false</enableCaptcha>
</securityRealm>

在配置文件里面怎么辨别使用是哪种权限控制模式？

节点上有个class属性，这个属性控制着使用那种授权模式

| hudson.security.FullControlOnceLoggedInAuthorizationStrategy 和 <denyAnonymousReadAccess>true</denyAnonymousReadAccess> 时，任何用户可以做任何事(没有任何限制)
| hudson.security.FullControlOnceLoggedInAuthorizationStrategy 登录用户可以做任何事
| hudson.security.ProjectMatrixAuthorizationStrategy 项目矩阵授权策略
| hudson.security.GlobalMatrixAuthorizationStrategy 安全矩阵
| hudson.security.LegacyAuthorizationStrategy 遗留模式

全局工具设置

全局工具设置，可配置JDK，Git，Gradle，Ant，Maven等工具，当然，默认情况下不显示全部工具的配置栏，必须安装相应的插件

从系统管理->全局工具设置进入配置页面
每个节点下都有Add(新增)按钮,点击Add按钮
- 安装JDK：不建议jenkins默认安装
- 安装Gradle：不建议jenkins默认安装
- 安装Maven：：不建议jenkins默认安装

管理节点

说到节点，不得不先说说Jenkins的分布式构建和部署功能了。Jenkins的分布式构建，在Jenkins的配置中叫做节点，分布式构建能够让同一套代码或项目在不同的环境(如：Windows和Linux系统)中编译、部署等，如下图：

Tips：目前我们使用节点的场景跟这个概念是不一样的，并不是分布式构建，而仅仅是为了微服务众多的机器便于代码部署。如果我们需要的话，同样可以进行分布式构建。

1）什么时候使用节点和节点作用

当我们使用多台服务器时，并且配置了tomcat或jboss集群服务，可通过jenkins的节点配置，将jenkins项目发布在不同服务器上（分布jenkins工作空间，部署项目到不同服务器的tomcat或jboss），这就形成了jenkins的分布式。节点服务器不需要安装jenkins（只需要运行一个slave节点服务），构建事件的分发由master端（jenkins主服务）来执行。

如我们jenkins部署dubbo框架rest服务时，会配置rest服务部署的那台服务器为节点，便于进行tomcat容器的管理。当然，其他没有使用dubbo框架的应用也可以这样使用，主要是方便容器的操作。

任何事情都会有很多种解决方法，类似上面的场景，通过ssh插件的方式也可以实现，或者直接写shell命令也可以实现。上面提到的节点，其背后的原理也是ssh，master机器通过ssh远程到对应的节点（slave）机器。

2）节点服务器的要求

注意：如果节点主机上不存在JDK，Jenkins会去自动下载，但Oracle对程序自动下载做了限制，会导致下载失败，然后一直循环这个问题。

建议：所有Linux或者Windows机器的环境路径统一(如：JDK、Maven)，安装位置和jenkins所在服务器的JDK和maven必须一致，也就是说jenkins所在服务器和各个节点服务器中的JDK和Maven目录和文件名都是一样的。以便于管理、不容易出现问题。

Tips：一般我都使用同一个JDK版本进行安装，安装方式也一样。如选择JDK版本jdk-8u66-linux-x64.rpm，安装方式为rpm -ivh jdk-8u66-linux-x64.rpm

3）新建节点

为了更快的创建节点，一般建议选择【使用复制现有节点】，如下图：

会根据输入的内容进行自动检索当前Jenkins服务中存在的节点，非常的方便，比如我们这里选择复制节点为tomcat_gyl

然后只需要修改对应的IP地址和认证即可

这里有几个选项特别说明下，否则在构建时容易出现一些诡异的问题

| 用法：有两种用法，一种是尽可能的使用该节点，一种是只允许运行绑定到这台机器的Job 。如果选择第一种用法，你在构建时就可能会出现，我本来想把服务部署在服务器A上面，实际上却部署在这台机器上，但由于这台机器没有服务所需的环境，最终失败了，所以百思不得其解原因所在。
| 启动方式：一般我们选择Launch slave agents via SSH 即可，其他几个启动方式如何使用的，大家自行研究
| Credentials：选择已有的认证，如果没有，点击【Add】添加，如下图：

目前我们使用最多的就是配置用户名密码的认证方式，也有使用私钥文件的认证方式

Tips:在首页Credentials可以修改、删除已有的认证内容

| 可用性：一般我们选择尽量保持代理在线

4）检查节点是否正常工作

一般情况下，节点配置完成保存后，会自动尝试从master连接到该节点机器，连接不成功会有一个红色的小叉

，至于连接失败的原因就要具体分析了，可能是认证方式没有配置正确，网络异常，防火墙，磁盘满了等。可以登录该节点机器，进一步确认，连接成功后，会自动在节点机器上启动两个java进程，如下图：

如果你手工断开该节点，这两个java进程就会自动退出

5）应用节点

节点创建好了之后，如何应用呢，我们在具体的Job中会根据所需来使用节点，如前面提到的rest服务部署，会配置需要的节点，如下图：

如果Job中配置了节点，那么后续进行的一些操作，如shell命令都是针对该节点进行操作的，非常方便

Tips：节点相关的所有配置信息都存储在Jenkins服务器/根目录/nodes下，如/trdata/nodes

可以看到我们前面创建的demo节点就在其中，进入demo目录可以看到就一个config.xml配置文件，内容如：

<?xml version='1.1' encoding='UTF-8'?>
    <slave>
        <name>demo</name>
        <description></description>
        <remoteFS>/usr/local</remoteFS>
        <numExecutors>1</numExecutors>
        <mode>EXCLUSIVE</mode>
        <retentionStrategy class="hudson.slaves.RetentionStrategy$Always"/>
        <launcher class="hudson.plugins.sshslaves.SSHLauncher" plugin="ssh-slaves@1.26">
            <host>10.200.xxx.xx</host>
            <port>22</port>
            <credentialsId>89f9f3ed-e417-413c-8c0c-75b1c03c70ed</credentialsId>
            <maxNumRetries>0</maxNumRetries>
            <retryWaitTime>0</retryWaitTime>
            <sshHostKeyVerificationStrategy class="hudson.plugins.sshslaves.verifiers.KnownHostsFileKeyVerificationStrategy"/>
        </launcher>
        <label></label>
        <nodeProperties/>
    </slave>

至此，节点的介绍就到这里了，下面开始讲解大家经常会接触到的Job相关操作，先来了解下Job

新建Project（Job）

简单说明下我们用到的和现在业界用的比较流行的：

| 构建一个自由风格的软件项目：这个是jenkins的基础功能,可以用它来执行各种构建任务,他只能构建在一个电脑上,如果没有太多的需求,这个job基本够用了,它包含了所有基础功能。有别于maven项目，在公司一般用于前端代码构建
| 构建一个maven项目：在公司一般用于服务端代码构建
| Pipeline：真实的工作环境有很多job，比如先编译，然后执行静态代码检查、单元测试、然后部署服务器、服务器重启、进行ui测试等。我们需要对这些job进行一些设置将它们的上下游关系配置好。这个时候就需要pipeline配置了（自行研究实践），大概效果如下：

| MultiJob Project：多项目构建，大致效果如下，后面会详细介绍：

| Folder：创建一个容器，将嵌套的项存储在其中。把东西分组在一起很有用。不像视图，它只是一个过滤器，一个文件夹创建一个单独的名称空间，所以你可以有多个相同名称的东西只要它们在不同的文件夹中

在服务器中文件目录结构

Tips：Jenkins迁移实际上就是文件的迁移

复制：最快捷的新建Job方式了，类似于前面提到的复制节点

Job配置

选择了对应风格的项目后，即进入到Job详细配置内容，详细配置内容分为几大部分：

1）General：一般配置

| Project name: 项目名称
| 描述: 项目描述,最好写清楚
| 启用项目安全：前提条件是安全配置中授权策略设置为【项目矩阵授权策略】
| 丢弃旧的构建:该选项配置如何抛弃旧的构建

每次构建相关的文件都会保存下来，将会渐渐耗光磁盘空间，为此提供以下方式供选择：
- | 保留构建的天数：如果其值为非空的N，就留N天之内的构建文件
- | 保持构建的最大个数：如果#为非空，就公保留最多#个最近构建的相关文件
- | 发布包保留天数：产品保留时间,但是log,历史记录会保留
- | 发布包最大保留#个构建：保留最近几个构建的产品
| 参数化构建过程:可以设置用户可输入的参数,没有输入则使用默认值,有字符串,多行字符串,布尔值等可以设置.wiki
| Throttle builds:设置两个build任务之间最小间隔和同一个时间内最大任务数量
| 关闭构建:停止这个job,当例如源码不可用时,可以暂时勾选这个停止build
| 在必要的时候并发构建: 如果可以会并发执行build.勾选上后.如果有足够的线程池则会并发,否则不会.并发构建会在不同的workspace中.如果用户自己设置的workspace则不会分开,这个是有风险的.
| 限制项目的运行节点: 设置是否必须在某个机器上运行.如果是分布式部署或者迁移job,注意移除或修改此项配置
| Quiet period：配置等待未发生提交变化的时间. 由于 jenkins检测到代码变化时,就自动立即构建，但是有些情况下，需要多次提交代码到版本控制系统上，此时,可能发生代码还没完整提交就开始构建,造成构建失败,为防止此种情况发生,可以配置值X,则jenkins会在代码变化后等待X秒,如果没在发生代码提交,才开始构建,保证稳定性。
| Block build when downstream project is building:该选项当多个相关联的项目由一个提交所影响，但是它们必须以一个指定的顺序进行构建的时候非常有用。当你选择这个选项的时候，Jenkins将会在启动这个构建之前，完成任何上游构建Job；例如使用pipes的时候

2）源码管理

3）构建触发器

| 触发远程构建 (例如,使用脚本)：外部通过url命令触发,拼接token和url就可以进行远程触发了
| 其他工程构建后触发：监控其他job的构建状态,触发此job.如监听代码提交,然后触发UITest,静态分析等
| 定时构建：定时触发.选择 Build periodically,在 Schedule 中填写 0 * * * .第一个参数代表的是分钟 minute,取值 0~59;第二个参数代表的是小时 hour,取值 0~23;第三个参数代表的是天 day,取值 1~31;第四个参数代表的是月 month,取值 1~12;最后一个参数代表的是星期 week,取值 0~7，0 和 7 都是表示星期天。所以 0 * * * 表示的就是每个小时的第 0 分钟执行一次构建。举个例子:每周六10点构建 0 10 * * 6,0-0分钟, 10-10点 -任意天 -任务月份 6-周六, 0可以改为H
| GitHub hook trigger for GITScm polling：**hookplugin检测到源码的push操作触发构建,感觉Poll SCM更方便些,如果提交频繁,则这个触发就会频繁,看业务需要设置
| 轮询 SCM：定时感知代码分支是否有变化,如果有变化的话,执行一次构建.示例：H/5 * * * * 每五分钟去检查一下远程仓库,看代码是否发生变化

4）构建环境

没啥特别好讲的，读者自行研究

5）构建

没啥特别好讲的，读者自行研究

6）构建后操作

可以根据build的结果设置发送邮件,打包,执行其他任务等等.build成功还是失败都会走到这一步

下面以两个示例来讲解我们当前经常会使用的Job，一种是构建一个自由风格的软件项目，一种是构建一个maven项目

构建一个自由风格的软件项目示例

实例演示

构建一个maven项目

实例演示

jenkins流程

总结

jenkins很强大,他的作用不仅仅是编译代码,还可以执行其他任意定时任务,监控任务.配合分布式部署,可以实现大规模的协作使用.

来源：CSDN

作者：Cappuccinooo

链接：https://blog.csdn.net/kuangay/article/details/80584104

标签

Jenkins

节点服务器

jenkins使用

软件

JDK

build

Jenkins实用教程