在上一章节简单介绍了使用jenkins部署服务到不同的机器上，但是对于在项目中的其它选项参数都没有过多介绍，所以本章的开始先简单的介绍一下项目中一些常用的参数选项。

项目配置

本小节以freestyle（自由风格）类型的项目为例，对不同步骤中涉及到的一些常用的选项参数进行简单的说明，需要注意的是，每个步骤中的参数选项会根据在Jenkins中安装的插件会有所不同，如果下面介绍到的某些选项参数在你的项目中不存在，有可能是插件没有安装，所以如果遇到这种情况，直接搜索所用的插件安装即可。

General

General 步骤主要是用来配置构建任务的一些通用配置，比如：

描述：该输入框内容自定义，也可以不写，出发点是用来记录该job任务的一些描述信息，比如该项目属于哪个组，服务的用途是什么等内容。

Discard old builds(丢弃旧的构建)：用于处理Jenkins项目构建的历史记录，”保持构建的天数” 和 “保持构建的最大个数”根据自己情况自定义。

This project is parameterized(参数化构建过程)：在非pipeline类型的job中这可能是用的比较多的一个参数，用于定义job构建过程中用到的一些参数，参数的类型很多，在下面会进行详细的介绍。

Throttle builds（控制并发的选项），用来设置两个任务之间最小间隔和同一个时间内最大任务数量，该功能用的很少，如果要使用此选项，则下面的”在必要的时候并发构建“参数需要勾选。

Restrict where this project can be run(限制项目的运行节点)：设置项目在指定的机器上运行。

源码管理

源码管理步骤这里不需要在过多介绍了，根据不同的源码仓库选择不同的代码拉取方式即可，对代码仓库的认证方式使用jenkins凭证，前面有过介绍，这里不再多说。

构建触发器

该步骤中使用介绍了几种使job任务自动构建的方法，比如：

Trigger builds remotely (e.g., from scripts)(触发远程构建 (例如，使用脚本))：用于在jenkins外部通过url命令触发，需要自己设置身份令牌（TOKEN_NAME），该参数在配置时已经给出了url的连接，比较简单。

Build after other projects are built：监控其他job的构建状态，触发此job构建。

Build periodically：周期进行项目构建，输入框内的填写方式参考linux中的crontab，如果”分时日月周”中有0，可以用H代替。

Poll SCM：用于定时检查源码变更，如果有变更就拉取代码并执行构建动作。如果没有更新就不会构建，同样遵循linux crontab的书写方式。

构建环境

构建环境步骤用于在任务构建之前所做的一些准备配置，比如：

Use secret text(s) or file(s)：用于绑定想要使用的jenkins凭证，该参数使用的插件为Credentials Binding Plugin。

Send files or execute commands over SSH before the build starts：在任务构建之前发送文件或者执行命令，该参数使用的插件为Publish Over SSH。

With Ant：使用ant，与maven工具类似，使用的插件为Ant Plugin。

构建

“构建“步骤可以理解为整个jenkins任务工作的核心了，在这个步骤中，对于中心任务的实现有多种方法，相应的参数选项也会比较多，这里会根据实际情况酌情介绍部分选项参数。比如：

Build/Pubilsh Docker image：用于根据指定的Dockerfile构建镜像并上传到私有仓库，使用的插件为Docker plugin。

invoke top-level Maven targets：前面有做简单介绍，这里不重复说明。

Conditional steps(multiple)：根据一个或者多个条件进行任务构建，默认自带的选项参数。

Deploy to Kubernetes：根据给定的文件部署资源对象到kubernetes集群，使用的插件为Kubernetes Continuous Deploy Plugin，后面会详细介绍。

Execute Docker command：用于执行docker命令或者，包括重启容器，拉取镜像、打包镜像等，基本上支持在bash shell中的所有docker子命令。

Execute sonarQube Scanner：执行sonar-scanner命令检测代码质量，用到的插件为Sonarqube scanner。

Exec shell：使用jenkins启动时设置的用户执行shell命令。

Invoke Ansible ..：在jenkins中使用ansible系列命令，用到的插件为jenkins ansible plugin。

Provide Configuration files：使用在jenkins中配置的某些服务或功能的配置文件，使用的插件为Config File Provider Plugin，在以后的章节中会介绍到。

Send files or execute commands over ssh：通过ssh发送文件或者执行shell命令，使用的插件为Publish Over SSH。

有关”构建”步骤中的选项参数就简单的介绍这么多，虽然在工作中不一定能全部用到，但是了解这些选项的用法对于灵活使用jenkins还是很有帮助的。

构建后操作

构建后操作可以算是Jenkins 任务的收尾工作了，在此步骤中，可以通过Archive the artifacts选项保存在上一步骤中的生成的归档文件；可以使用E-mail Notification选项发送构建详情等信息通知管理人员；也可以使用publish over ssh插件发送部署文件或执行命令或者使用Build other project选项根据条件构建其他任务等。

关于Jenkins项目配置的部分选项参数就简单的介绍到这里，对于一些选项的使用在以后的章节中会进行详细的介绍。

参数化构建过程

实际工作中，在Jenkins UI中配置job或者编写pipeline流水线的时候，为了提高Jenkins Job的灵活性，肯定会有用到变量的情况。变量的值除了可以使用Jenkins内部预设的变量，也可以使用从外部传入的变量。而这些从外部传入的变量，在配置jenkins Job时，大多数都是以参数化构建的方式定义的。

使用参数化构建，可以根据实际情况定义自己想要设定的参数，jenkins参数化构建选项提供了十多种类型的参数定义，下面针对一些常用类型的参数定义做一个简单的说明。

Boolean Parmeter

布尔型参数，该类型的参数的值只能是true或者false。

示例如下，勾选This project is parameterized，从”添加参数“下拉列表中点击”Boolean Parameter“

在”构建”步骤使用Exec shell编写如下脚本：

#!/bin/bash

if ${test_boolean} is true:
then
    echo "参数勾选了"
else
    echo "参数没有勾选"
fi

传递的参数需要通过${参数名称}引用。

保存后点击Build with Parameters，如下所示：

构建结果这里就不展示了，有兴趣的自己测试一下。

Choice Parameter

选择参数，在jenkins中定义一个参数值列表，构建时通过选定的值传给参数，并被其他步骤引用。

示例如下：

在”构建”步骤中在”Exec shell” 输入框中输入命令。

#!/bin/bash

echo "current command: git clone $branch http://192.168.176.154/root/test-helloworld.git"

保存后执行job。

构建时可以根据下拉列表中的分支拉取代码。构建结果自己测试即可。

File Parameter

文件参数用于从浏览器表单提交中接受一个文件，并作为构建参数。上传后的文件将会放在当前工作空间（$WORKSPACE）中指定的位置，你可以在构建任务中访问并使用它。

如下示例：

说明：

表单提交中的文件名称就是文件的路径，并且是在环境变量中可见的。但是引用该文件时，直接使用自定义的文件路径即可。例如：把文件放到当前工作目录的test目录（不存在会自动创建）下，使用时直接使用该文件路径，而不用使用变量。

在”构建“步骤中的”Exec shell” 输入框中输入命令：

#!/bin/bash

cat $WORKSPACE/test/test.xml

点击保存后执行，即可查看该文件的内容。

Extend choice Parameter

顾名思义，可扩展的选择参数，相比于choice Parameter只能使用单个参数选项外，该参数可以同时定义多个参数选项，并为每个参数选项设置不同的值，该参数使用插件为Extended Choice Parameter Plug-In。

首先看一下该参数支持的参数类型：

其中：

“Name 和Description”参数为自定义。- 该参数支持的类型主要为单选、多选框和输入框，至于hidden用处不大，这里不做介绍。

单选类型参数

Single Select和Radio Butions均为单选框。

首先看一下Single Select类型，选择该类型后，点击构建时多个参数会组成一个下拉列表。

其中：

Name：为该参数的名称。- Description：该参数的描述。- Parameter Type：为参数类型，这里选择的是single select。- Number of Visible Items：可用的参数的数量。- Delimiter：如果设置了多个参数，每个参数之间的分隔符。

参数值设置：

说明:

Choose Source for Value：该参数得值，必须项。- Choose Source for default Value：该参数的默认值，非必须。- Choose Source for Value Description：关于该参数值的描述，非必须；如果没有设置该选项，在执行job的时候，在参数后面的下拉列表中会直接显示该参数的值；如果设置了才参数，在执行job的时候，在参数后面的下拉列表中会直接显示该参数的值的描述，也就是此参数设置的值，需要注意的是，如果设置了此参数，此参数的值数量，要与设置的value的值的数量相同，如果数量不相同，最后的一个值会使用设定的Value的值填充，效果可以看下面。

在”构建“步骤中的”Exec shell” 输入框中输入命令：

#!/bin/bash

echo $test_extend_choice 

执行时效果如下所示：

说明：

在配置job时，对于最后一个job的描述值没有填写，这里就会直接显示value的值。- 此时如果选择para1并执行，就会打印值value1。

如果设置了基础参数类型为Radio Butions时，构建job时，显示的是这样的：

这里可以看到在选择参数值的时候出现了滚动条，这是因为在设置”可用的参数的数量“的时候，设置的值比实际的参数的数量少造成的，所以为了美观，建议有多少个参数就设置”可用的参数的数量”为多少。

其他设置与使用Single Select时一样，这里不再多说，有兴趣的可以自己试验一下。

多选类型参数

如果设置了多选框，在执行jenkins任务的时候可以设置多个选项参数，并使用这些参数指定的值，多选框的类型为Multi Select和Check Boxes，首先看一下基础版本。

在”Exec Shell“输入框中输入：

#!/bin/bash

echo $key

测试一下，执行时会输出选定的key的值。

选定哪个参数，就会输出哪个参数对应的值。

除了使用单个Extend choice Parameter以外，也可以创建多个Extend choice Parameter组合使用。

示例

比如下面示例：在部署微服务应用的时候，常常会遇到多个微服务应用构建时依赖同一个公共服务的情况，此时在部署多个微服务应用的同时，可以先构建公共服务，在构建应用服务。

首先，如果多个项目依赖一个公共服务的情况，第一个Extend choice Parameter参数可以使用单选框类型，为了美观以及更清楚地列出公共服务列表，我使用Radio Buttons类型的参数，如下所示：

说明：

定义一个依赖服务参数，参数选择类型为单选，定义两个参数值，build和not_build，对应的描述分别为”构建依赖服务”和”不构建依赖服务”。

第二个Extend choice Parameter参数配置如下：

说明：

该参数名称为app_service，描述为应用服务。

在”Exec Shell“输入框中输入如下脚本。

#!/bin/bash

string=$app_service
array=(${string//,/ })

build_job(){
    for service in ${array[@]}
    do
    {
        echo  "并行构建 $service " 
    }&
    done
    wait

}

if [ "$dependency_service" == "build" ]
then
    echo "构建依赖服务xxx"
    build_job
else
    echo "不构建依赖服务"
    build_job

fi

执行如下所示：

结果如下：

其次，如果有多个公共服务的时候，可以使用多选框类型的选择参数进行配置，参考上面示例中应用服务的配置即可。

除了使用Check boxes作为多选的选择参数以外，还可以用Multi Select，只不过该参数在选择多个参数选项的时候需要按住ctrl键，操作起来比Check boxes略显麻烦，其它都没什么特殊变动，这里就不在演示了，有兴趣的可以自己尝试一下。

输入类型参数

输入类型参数就比较简单了，定义了参数之后，参数类型直接使用Text Box类型，然后在构建时输入参数的值即可，一般用的不多。

Git Parameter

Git Parameter主要用于在构建job之前预先从”源码管理“步骤中设定的git源码库中获取该源码仓库的git标记（支持的git标记包括标签、分支、分支或标签、修订、Pull Request），并根据标记拉取git代码进行构建。

如下所示，点击”Build with Parameter”后会自动列出设定的源码仓库的git标记（列出的标记根据设定的git标记类型会有所不同，此示例使用的git标记为分支）。

job设置如下：

其中：

• 参数类型可以根据自己实际情况选择
• 默认值为必须要填写的参数

此时在设置”源码管理”的时候需要设置分支为上面创建的参数变量。

说明：

• Branches to build 虽然名称为指定的分支，但是对于上面提到的各种git标记放到这里都是可用的。

Password Parameter

密码类型的参数：如果在配置Jenkins任务的时候不想在job中或者console log中显示明文密码，可以使用该参数，如下所示，可以给该参数设置一个默认值。

比如在登录私有docker hub仓库的时候使用该参数。

#!/bin/bash

docker login 192.168.176.155 -u admin -p $test_password_para

虽然整个过程是加密的，但是在exec shell中通过echo $test_password_para命令还是能够获取明文密码的，并且涉及到密码的使用，Jenkins凭据会比使用该参数更有优势，所以此参数还是根据个人情况使用吧。

String Parameter

字符串参数，最普通的参数，类似于Extend choice Parameter中的输入类型参数，比较简单，这里就不演示了，有兴趣的可以自己尝试一下。

有关参数化构建的内容就简单的介绍到这里。

变量

在Jenkins job中除了可以使用上面自定义的变量外，还可以使用Jenkins中内置的环境变量，内置的环境变量可以在job的任何配置步骤中使用，可以通过http://Jenkins_URL/env-vars.html/获取所有的内置变量。如下所示：

……

变量很多，但是在工作场景中用的比较频繁也就那么几个，比如WORKSPACE变量，该变量表示当前job的工作空间，也是该job在Jenkins服务器上的绝对路径；BUILD_NUMBER变量表示当前job的构建ID；JOB_NAME表示当前job的名称，也就是jenkins的项目名称。比如在”Exec shell“中输入。

echo $WORKSPACE $BUILD_NUMBER $BUILD_ID $JOB_NAME

构建job后输出的内容如下：

关于其他变量的介绍可以自己去试一下，这里不做过多介绍。

视图

使用jenkins的过程中，如果Job数量特别大，想快速定位想要构建或者修改配置的Job、或者想要对同一个项目组中Job任务进行统一管理，可以通过在Jenkins中建立视图来对Job进行管理。jenkins中的视图类似于电脑上的文件夹。默认jenkins中有一个All的视图，所有的项目均会在此视图下列出。

创建视图

下面创建一个视图。

在Jenkins的主面板点击”New View“选项（也可以点击All视图右面的”+“按钮），在跳转的界面中输入视图名称，如下图所示：

其中：

• List view选项比较简单，用于从全局job列表中自定义选择要放到该视图下的Job，选择Job时可以通过条件过滤或者正则表达式匹配想要放到该视图下的Job；同时对于该视图中的显示Job信息的列的字段名称进行自定义添加或者删除，如下所示

  

  根据自己实际需求配置即可。

• My View选项将会将当前用户所能看到的所有job添加到新创建的视图中。

• Pipeline Aggregator View选项用于在jenkins系统中全屏显示pipeline类型job的staeg和Job构建属性信息等，一般用处不大。

配置好点击保存就创建了视图。

如果想要删除视图，在点击视图名称后，直接在jenkins面板中点击”删除视图”即可。并且视图删除后，job任务不会被删除。

凭据

凭据（cridential）是Jenkins访问第三方应用时的认证信息。凭据可以是账号/密码、SSH密钥、加密文件等。Jenkins可以通过设置的凭据与其它第三方应用在可信与可控的范围内进行交互。为了提高安全性，Jenkins会对凭据进行加密存储，使用该凭据时默认使用凭据ID与第三方应用认证。

Jenkins默认可以存储以下类型的凭据：

• Secret text - API token之类的token (如GitHub个人访问token),
• Username and password - 用户名和密码
• Secret file - 保存在文件中的加密内容
• SSH Username with private key - SSH 公钥/私钥对
• Certificate - PKCS#12 证书文件和可选密码

而如果安装了像docker、kubernetes、openshift这类插件的情况下，也会增加对这类系统的凭据类型：

• Docker Host Certificate Authentication - Docker 仓库认证信息
• Kubernetes configuration（kubeconfig）：对kubernetes容器编排系统的认证
• openshift usernanme password：对openshift系统登录的认证

创建凭据

在jenkins主面板中点击”凭据（cridential）”—>”系统（system）”—>”全局凭据（Global credentials）(unrestricted)“，如下所示：

在跳转的界面中点击”添加凭据（add credentials）“，以创建一个Username with password类型的凭据为例。

如下所示：

这里需要说一下ID参数，ID参数的值可以自定义，如果不填写，jenkins会自动生成一个ID，至于如何使用这个凭据，将在下面的”创建jenkins项目”小节中介绍。

Jenkins凭据在持续交付和部署过程中使用比较频繁，在以后的章节中会介绍多种类型的凭据的创建，本节有关凭据的内容就简单的介绍到这里。

配置Master-Slave

使用jenkins的时候，为了避免Jenkins服务所在的主机资源消耗过大，影响Jenkins服务的性能，往往会增加一个或多个slave节点来专门执行Jenkins任务，这就是我们熟知的Jenkins的Master/slave架构。

Jenkins 的Master/Slave架构相当于Server和agent的概念。Master提供web接口让用户来管理job和slave，job可以运行在master本机或者被分配到slave上运行。一个Master可以关联多个slave用来为不同的job或相同的job的不同配置来服务。

配置Jenkins slave节点不需要安装jenkins服务，只需要将jenkins主节点使用的一些基础工具（本系列课程用到jdk、maven、git、ansible、docker、sonar等工具栈）等安装配置好就可以了。jenkins的slave节点可以是虚拟机，也可以是容器，可以是静态的主机资源，也可以是动态的容器资源，鉴于使用动态的容器资源需要相关的jenkins插件方面的知识，这里就先介绍一下如何添加静态的主机节点。

点击 “Manage Jenkins(系统管理)”–> “Manage Nodes(节点管理)“，可以看到目前只有一个master节点，点击左侧的”New Node“，给该slave节点设置一个名字，比如我这里为”slave1”，点击确定，

说明：

• of executors（并发构件数量）：表示同时进行构建的任务数量，根据自己情况填写。

• Remote root directory(远程工作目录)：为必填项，里面用来保存拉取的应用代码，根据自己情况设定。

• Labels（标签）：该slave节点的标签，在Jenkins 项目里可以通过该标签匹配到slave节点。

• Usage：用于设置使用该节点的策略，可以设置为尽可能多的使用该节点（如上所示），也可以设置为only build jobs with label expressions matching this node，表示只有jenkins job中设置了指定job任务在该节点运行才会使用该节点。

• Launch metheod：用于配置jenkins slave节点的启动方式，主要分为ssh和jnlp两种，其中ssh为master主动连接slave节点，jnlp为slave节点主动连接agent，图上的配置使用的ssh方式。

Host（主机）：这里写Jenkins Slave服务器的地址。

Credentials(凭据)：这里需要添加一下登录Slave服务器的用户名和密码。

Advanced（高级）：用来设置该服务器的一些相关信息。

port：如果服务器ssh端口不是22，可以设置成别的。

JavaPath：这里需要设置一下 slave服务器java可执行文件的绝对路径。比如我的配置为（/usr/local/jdk1.8.0_231/bin/java）。

设置完成后，点击最下方的保存按钮。在跳转到的界面，然后点击launch Agent按钮。日志如下表示添加节点成功。

节点添加成功后，可以修改jenkins项目配置，勾选Restrict where this project can be run，在出现的框中输入slave节点的名称或者label，保存后再次构建该项目，就会在新添加的节点构建该项目。如下所示：

除了使用vm虚拟机作为jenkins的slave节点以外，也可以使用docker容器作为jenkins的slave节点，同时slave节点也可以通过容器编排工具进行编排，在以后的章节中这些内容都会介绍到，并且对于常用的使用动态slave作为job执行的环境的内容也会进行说明，敬请期待。

有关jenkins项目配置内容到这里就结束了，在后面的章节开始进入实践阶段。