点击下载：《jenkins安装》
正文
以下内容由word文档直接导入，虽然排版差劲一点，但是可以方便大家可以在线查阅。
Jenkins搭建与使用
安装jenkins
Jenkins搭建在物理机上，1个master做调度，N个slave执行任务。
我们只在master安装Jenkins，配置slave节点后，master会通过ssh连接到slave自动部署slave进程，这一点还是很方便的。
准备2台ubuntu服务器，下面开始搭建。
搭建master
参考：https://pkg.jenkins.io/debian-stable/ https://jenkins.io/zh/doc/book/installing/
添加一个apt的东西：
wget -q -O – https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add –
编辑/etc/apt/sources.list文件，添加如下一行：
deb https://pkg.jenkins.io/debian-stable binary/
然后开始安装java和jenkins：
apt-get update
apt-get install openjdk-8-jdk
apt-get install jenkins
安装后jenkins就启动了，为了让它有足够的权限访问docker之类的，我们修改一下/etc/default/jenkins，把运行用户改成root：
JENKINS_USER=root
JENKINS_GROUP=root
然后重启systemctl restart jenkins
Jenkins的所有程序以及数据存放在目录/var/lib/jenkins下。
浏览器访问8080端口可以进入jenkins，默认登录账号：admin，密码查看：cat /var/lib/jenkins/secrets/initialAdminPassword。
根据引导安装推荐插件即可，期间可能因为GFW会导致部分插件安装失败，修复方法如下：
进入插件管理，替换一下插件仓库：
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
搭建slave
进入slave机器，改一下root密码：
sudo su root
passwd
修改ssh允许root用户登录：
vim /etc/ssh/sshd_config
修改如下的行：
PermitRootLogin yes
然后重启ssh：
systemctl restart ssh
回到master机器，生成rsa：
ssh-keygen
将pub拷贝到slave上，以便master免密登录slave：
ssh-copy-id root@172.18.11.9 ，输入slave的密码，然后可以在slave上看到~/.ssh/authorized_keys文件了，试一下ssh可以从master登到slave即可。
回到slave机器，创建slave的工作目录：
mkdir -p /var/lib/jenkins/
安装java环境：
apt-get update
apt-get install openjdk-8-jdk
添加slave到master
回到master，进入系统设置->节点管理，添加一个从节点：
并发构建数用于控制同时执行的任务数量，slave就1个cpu所以就写了1，也可以多写。
工作目录/var/lib/jenkins，刚才我建的。
可以给节点打上label，这样后续可以为特定任务指定执行节点，我这里打一个slave标签，后续我们让任务都在slave上执行，保证master资源充足。
启动方式配置slave机器的IP，点击add添加ssh配置（如下图），这样master就可以通过ssh连到slave上部署slave进程了。
帐号是slave的root，私钥是master的~/.ssh/id_rsa，因为我们配置了slave信任master，所以只要master用私钥加密ssh请求就可以证明自己的身份了，很常规的ssh免登要求。
Host Key Verification Strategy照选即可，即首次ssh连接slave需要我们人工确认一次。
一切正常可以看到slave节点：
进入slave机器，查看/var/lib/jenkins目录有数据出现：
Slave进程也启动了。
配置实战
Jenkins核心就是用pipeline功能配置CI/CD流程，其基本骨架教程：https://jenkins.io/doc/book/pipeline/ 。
在具体pipeline的时候会有很具体的目标，需要用到jenkins提供的各种具体指令，可以打开：http://IP:8080/pipeline-syntax/，可视化的选择与生成指令。
片段生成器和Declarative Directive Generator都很有用。
下面我制定一个小目标：
- 准备一个centos的base镜像，里面提前安装了标配的nginx和php环境，把镜像存到harbor中。
- 每个接入项目在根目录下放一个build.sh脚本，在pipeline中会调用给应用一个自定义构建的机会，要求build.sh产出一个deploy.tar.gz文件，它将被打入到镜像中。
- 在deploy.tar.gz中，要求放一个deploy.sh脚本，镜像启动后会先执行deploy.sh给应用部署的机会（比如把代码放到webroot下，把nginx server配置文件放到指定目录），然后镜像会令nginx重新加载配置，容器就算启动完成了。
构造nginx+php基础镜像
nginx
拉一个centos:6的镜像，进去把nginx和php都装一下，然后再保存这个镜像到harbor作为base镜像即可。
下载centos（版本7的systemctl有点问题，我们用6就行）：
docker pull centos:6
后台运行centos6：
docker run -d centos:6 sh -c ‘while true; do sleep1; done’
找到容器ID：
docker ps
连接到容器里（写dockerfile太麻烦，直接进去装程序好了）：
docker exec -it c600aeab916f /bin/bash
安装vim：
yum install vim
安装nginx（参考：）
vim /etc/yum.repos.d/nginx.repo
添加
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/6/x86_64/
gpgcheck=0
enabled=1
然后yum install nginx完成安装。
删除nginx自带的80端口服务：/etc/nginx/conf.d/default.conf，然后拉起执行/etc/init.d/nginx start启动nginx。
我们现在可以配置/etc/nginx/nginx.conf改公共基础配置，后续我们的PHP应用只需要把自己的配置放到conf.d目录即可。
现在把这个容器保存到镜像中持久化下来：
docker commit de04b78f32e8 php-base:v1
php
回到容器中：docker exec -it c600aeab916f /bin/bash
现在安装php（参考https://www.tecmint.com/install-php-7-in-centos-6/，随便用yum一安吧，以后生产环境还是自己编译PHP）：
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
yum install http://rpms.remirepo.net/enterprise/remi-release-6.rpm
yum install yum-utils
yum-config-manager –enable remi-php71
yum install php php-bcmath php-cli php-common php-devel php-fpm php-gd php-imap php-ldap php-mbstring php-mcrypt php-mysqlnd php-odbc php-pdo php-pear php-pecl-igbinary php-xml php-xmlrpc php-opcache php-intl php-pecl-memcache php-pecl-redis
然后启动php：
/etc/init.d/php-fpm start
然后再保存一下镜像：
docker commit de04b78f32e8 php-base:v2
测试
创建目录：
mkdir -p /data/webroot/phpsrc/test
编辑/data/webroot/phpsrc/test/index.php:
<?php
echo ‘hello world’;
编辑/etc/nginx/conf.d/test.conf：
server {
listen 809;
server_name test.smzdm.com;
root /data/webroot/phpsrc/test;
charset utf-8;
location / {
index index.php;
if (!-e $request_filename){
rewrite ^(.*)$ /index.php last;
break;
}
}
location ~ \.php$ {
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 128k;
fastcgi_buffers 32 32k;
include fastcgi_params;
port_in_redirect off;
fastcgi_pass 127.0.0.1:9000;
}
}
然后热加载nginx配置：
/etc/init.d/nginx reload
访问测试：
curl localhost:809
打印了：
hello world
说明nginx和php可以按照预期工作，我们只需要把PHP代码和nginx配置放到对应位置，就可以工作了。
上传镜像
我自己搭了harbor私有仓库，所以我把镜像改改名推上去（没有Harbor的直接推到docker hub就行）：
docker tag php-base:v2 harbor.smzdm.com/smzdm/php-base:v2
docker push harbor.smzdm.com/smzdm/php-base:v2
这样harbor仓库中就有项目了：
我们可以把本地的镜像删了，拉一个下来试试：
docker rmi harbor.smzdm.com/smzdm/php-base:v2
docker pull harbor.smzdm.com/smzdm/php-base:v2
重新运行一个容器
docker run -d harbor.smzdm.com/smzdm/php-base:v2 sh -c ‘while true; do sleep 1; done’
连接上去：
docker exec -it e9eb132e446cf37679220da9be35a40ad8420be57b582328a3b7664ba745f02c /bin/bash
启动nginx和php：
/etc/init.d/nginx start
/etc/init.d/php-fpm start
访问测试：
curl localhost:809
创建PHP测试项目
现在申请一个github项目，里面放一个index.php文件，然后写好build.sh和deploy.sh脚本。
我的PHP项目地址：
https://github.com/owenliang/jenkins_test_project
在里面放一个index.php，是我们唯一的项目代码：
<?php
echo ‘hello jenkins!’;
然后编写一个nginx配置test.conf，后续要放到/etc/nginx/conf.d/test.conf：
server {
listen 809;
server_name test.smzdm.com;
root /data/webroot/phpsrc/test;
charset utf-8;
location / {
index index.php;
if (!-e $request_filename){
rewrite ^(.*)$ /index.php last;
break;
}
}
location ~ \.php$ {
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 128k;
fastcgi_buffers 32 32k;
include fastcgi_params;
port_in_redirect off;
fastcgi_pass 127.0.0.1:9000;
}
}
build.sh
编写build.sh编译脚本：
#!/bin/bash
# 该PHP项目最终要部署到/data/webroot/phpsrc/test下面
rm -rf deployment
# 代码
mkdir -p deployment/code
cp index.php deployment/code
cp test.conf deployment/
# 部署脚本
cp deploy.sh deployment/
# 打包目录
cd deployment
tar czvf ../deploy.tar.gz *
cd –
# 删除临时目录
rm -rf deployment
Jenkins pipeline会先checkout项目代码，然后执行其中的build.sh来自定义构建项目，build.sh产出一个结果叫做deploy.tar.gz，由pipeline拿来继续做docker镜像的构建。
deploy.sh
编写deploy.sh部署脚本：
#!/bin/bash
# 代码部署到test目录
cp -r code/* /data/webroot/phpsrc/test
# 部署nginx配置
cp test.conf /etc/nginx/conf.d/
Jenkins pipeline在build.sh之后，会基于dockerfile构建镜像，即首先解压deploy.tar.gz到之前制作的base镜像某个目录下，并指定容器启动命令为：先执行deploy.sh，再拉起php-fpm，最后拉起nginx。
至此，我们的PHP测试项目就完成了，包含了index.php，build.sh，
deploy.sh，把它们上传到github。
接下来要干嘛呢？就是编写dockerfile，把base镜像和deploy.tar.gz打包到一起，生成后续用来上线用的docker镜像文件。
构建镜像
假设jenkins pipeline执行了build.sh得到了deploy.tar.gz，接下来要把部署文件打包到base image里，这样还不足够，我们还需要指定容器ENTRY命令，也就是容器启动后执行deploy.sh，以及拉起php和nginx。
为什么不在build镜像阶段执行deploy.sh呢？因为deploy.sh在我的定义中是一个运行时的回调，很有可能它还要启动点什么别的东西，所以需要放在容器的启动命令中执行。
所以，我们先写dockerfile并做好测试，只要dockerfile好用，我们后面要做的无非就是在jenkins去执行dockerfile完成构建而已。
编写dockerfile
我们新建一个github项目，用来存放jenkins构建项目过程中要用到的文件： https://github.com/owenliang/jenkins_tools.git ，现在我们要保存的就是php类型项目的通用dockerfile文件：
# PHP项目 – 通用dockerfile
# 包含PHP和NGINX环境的基础镜像
FROM harbor.smzdm.com/smzdm/php-base:v2
# 接下来的构建工作目录，是容器内的
WORKDIR /root/deploy
# 把build.sh产生的部署包解压到WORKDIR目录
ADD [“deploy.tar.gz”, “./”]
# 容器启动命令
ENTRYPOINT sh deploy.sh && /etc/init.d/php-fpm start && /etc/init.d/nginx start && while true; do sleep 1; done
构建时会把deploy.tar.gz通过ADD命令，解压到镜像的/root/deploy目录。
启动容器时，会执行/root/deploy下的deploy.sh，并且拉起php-fpm和Nginx，最后while sleep保证容器不退出，除了deploy.sh的命令可以放在一个脚本例，一起ADD到容器里比较好。
测试构建
我们可以直接拿着这个dockerfile，以及build.sh出来的deploy.tar.gz做个实验：
在jenkins机器上，把2个github项目都拖下来：
git clone https://github.com/owenliang/jenkins_test_project.git
git clone https://github.com/owenliang/jenkins_tools.git
进入test_project做build.sh，生成deploy.tar.gz：
把php通用的dockerfile拷贝到当前目录下：
cp ../jenkins_tools/dockerfile-php ./Dockerfile
然后build构建（-t指定生成镜像的名字，在jenkins中应该使用”项目名:构建版本”这样的结构; 后面的.是build的宿主机上下文，例如COPY命令会从这个目录寻找文件）：
docker build -t ‘harbor.smzdm.com/smzdm/test:beta’ .
可以查看镜像：
启动容器：
root@harbor01:~/jenkins_test_project# docker run -d harbor.smzdm.com/smzdm/test:beta
8a6bb8c08d06420a2e12bc2e717f3e7834ee1f5f3706b10b9ff400255c1ce044
然后连接上去：
请求成功！
下面是容器内的WORKDIR工作目录，可见代码被解压到镜像里了：
Webroot下部署了test项目：
Nginx配置：
推送镜像
Jenkins构建完镜像，下一步肯定是把image传到harbor仓库里，等待上线使用了，这一步通过docker push就可以搞定。
未来可以在发布系统中，调用harbor的API获取镜像列表，从而发起上线，这是后话。 
推送瞬间完成，为什么这么快呢？ 因为docker是层叠文件系统，我们这个镜像只是多了一层代码，所以只需要把新增的layer上传harbor，所以很快，也很节约仓库的磁盘。
基于pipeline自动构建
我们使用Jenkins一定要考虑如何N个项目如何统一配置的问题，否则一个项目一个pipeline配置，一旦要调整构建流程，每个项目的pipeline文件都得改一遍，显然是扯淡。
也就是说，我们整个团队应该只维护一份Pipeline的配置文件，所有同类型的项目构建流程都是一样的。
不同项目可以通过params参数化的方式对公共pipeline流程进行干预控制，从而实现一套配置N个项目的效果。
美团有一些说明：https://tech.meituan.com/erp_cd_jenkins_pipeline.html
搭建骨架
我之前有一个https://github.com/owenliang/jenkins_tools 项目，它除了存放dockerfile用于构建镜像之外，还应该存放我们的公共pipeline配置，也就是一个Jenkinsfile。
我们后续接入jenkins的所有项目，都会使用这个jenkinks_tools项目中的Jenkinsfile来运行pipeline流程。不同项目要做的事情，就是配置自己的参数来指导pipeline流程。
创建任务
我们要构建的项目是https://github.com/owenliang/jenkins_test_project，所以我起名叫做：test_project吧：
Jenkins支持指定Jenkinsfile从哪里加载，触发时jenkins会首先帮我们把jenkinsfile下载回来，而jenkinsfile里面就定义了通用的pipeline流程。
我现在假设已经写好了jenkinsfile-php放在了https://github.com/owenliang/jenkins_tools 项目里，那么就这样配置一下：
Credentials是可以配置下载git代码的账号与密码，我这里github是开放的，所以就不配置了。
Branches指定了构建哪个分支，指定master即可，我们所有的jenkinsfile都放在jenkins_tools的Master里面。
保存一下上述配置，然后我们编写一个没有任何功能的jenkinsfile-php上传到jenkins_tools项目下：
pipeline {
agent any
stages {
stage(“下载代码”) {
steps {
echo “下载代码”
}
}
stage(“构建应用”) {
steps {
echo “构建应用”
}
}
stage(“打包镜像”) {
steps {
echo “打包镜像”
}
}
stage(“推送镜像”) {
steps {
echo “推送镜像”
}
}
}
}
然后触发一下test_project的构建流程：
看到结果成功：
Pipeline骨架就搭建好了，接下来就是填充每个stage的细节工作了。
Stage 下载代码
编辑test_project的配置，添加一个params记录该项目的源码下载路径：
我们要让pipeline在stage(“下载代码”)阶段，使用git命令把params.APP_REPO下载回来，所以打开jenkins的：http://172.18.10.236:8080/job/test_project/pipeline-syntax/ ，点击片段生成器，点击checkout指令，填入必要信息，点击生成：
自动生成了这段指令：
checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [[$class: ‘RelativeTargetDirectory’, relativeTargetDir: ‘app_repo’]], submoduleCfg: [], userRemoteConfigs: [[url: ‘${params.APP_REPO}’]]])
图形化生成非常方便，这段指令放在pipeline step里就可以完成代码下载，并且代码被下载到子目录app_repo中。
其中需要改一个地方就是${params.APP_REPO}这个参数，得改用双引号，否则pipeline不会替换为真实的值：
checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [[$class: ‘RelativeTargetDirectory’, relativeTargetDir: ‘app_repo’]], submoduleCfg: [], userRemoteConfigs: [[url: “${params.APP_REPO}”]]])
我们把它贴到pipeline中，把pipeline上传github：
然后重新执行构建： 
观察pipeline的控制台输出： 
可见，pipeline在app_repo目录下拉取了github上的jenkins_test_project项目代码，放在了构建目录下（workspace/test_project/app_repo）。
Stage 构建应用
很简单，我们给stage(“构建应用”)增加相关step：
pipeline {
agent any
stages {
stage(“下载代码”) {
steps {
echo “下载代码”
checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [[$class: ‘RelativeTargetDirectory’, relativeTargetDir: ‘app_repo’]], submoduleCfg: [], userRemoteConfigs: [[url: “${params.APP_REPO}”]]])
}
}
stage(“构建应用”) {
steps {
echo “构建应用”
sh “cd app_repo && sh build.sh”
sh “cp app_repo/deploy.tar.gz ./”
}
}
stage(“打包镜像”) {
steps {
echo “打包镜像”
}
}
stage(“推送镜像”) {
steps {
echo “推送镜像”
}
}
}
}
第一步进入app_repo目录执行build.sh，第二步把产出的deploy.tar.gz拷贝到构建根目录下。
每一个step，jenkins都会重置当前工作目录为构建根目录，这个路径关系我们要搞清楚。
上述就是构建后的效果，jenkinsfile-php就是当前pipeline的配置，app_repo是项目源码，deploy.tar.gz是app_repo里build.sh出来的，dockerfile-php是我们接下来要用来打镜像的。
Stage 打包镜像
继续修改pipeline：
pipeline {
agent any
stages {
stage(“下载代码”) {
steps {
echo “下载代码”
checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [[$class: ‘RelativeTargetDirectory’, relativeTargetDir: ‘app_repo’]], submoduleCfg: [], userRemoteConfigs: [[url: “${params.APP_REPO}”]]])
}
}
stage(“构建应用”) {
steps {
echo “构建应用”
sh “cd app_repo && sh build.sh”
sh “cp app_repo/deploy.tar.gz ./”
}
}
stage(“打包镜像”) {
steps {
echo “打包镜像”
sh “cp dockerfile-php Dockerfile”
sh “docker build -t ‘harbor.smzdm.com/smzdm/${currentBuild.projectName}:${currentBuild.id}-${currentBuild.startTimeInMillis}’ .”
}
}
stage(“推送镜像”) {
steps {
echo “推送镜像”
}
}
}
}
在构建根目录下准备好对应的Dockerfile，然后build镜像，我们之前写的dockerfile会把deploy.tar.gz打包到镜像里。
-t指定生成的镜像名字，镜像最终要推送到私有仓库harbor.smzdm.com，属于smzdm项目，镜像名是currentBuild.projectName，也就是jenkins配置的pipeline项目名：test_project。
currentBuild .id是每次构建任务的唯一标识，currentBuild .startTimeInMills是构建开始的时间，这些都是jenkins内置变量，详细信息参考： http://172.18.10.236:8080/pipeline-syntax/globals#currentBuild
Docker build会根据dockerfile去私有仓库拉取镜像，我们可以提前在jenkins部署的机器上做好docker login登录，也可以在steps里配置一个docker login登录步骤，我在最后推送镜像的部分做一个演示。
Stage 上传镜像
下面先演示一下如何通过命令行登录docker私有仓库。
正常来说，我们想访问docker仓库需要登录：
docker login harbor.smzdm.com -u admin -p Harbor12345
就可以登录到私有仓库，并且密码会被保存下来，后续就不用登录了：
cat ~/.docker/config.json
{
“auths”: {
“harbor.smzdm.com”: {
“auth”: “YWRtaW46SGFyYm9yMTIzNDU=”
}
}
如果我们没有在机器上登录过docker仓库，那么可以把上述登录命令写在pipeline的流程里，就像这样：
stage(“推送镜像”) {
steps {
echo “推送镜像”
sh “docker login harbor.smzdm.com -u admin -p Harbor12345”
sh “docker push ‘harbor.smzdm.com/smzdm/${currentBuild.projectName}:${currentBuild.id}-${currentBuild.startTimeInMillis}’ ”
}
}
我们的pipeline配置是上传在github的，我肯定不希望密码如此暴露给公众，怎么办呢？
可以把帐号密码保存在jenkins里，jenkins可以通过env环境变量的形式把帐号密码注入到pipeline中使用。
我们先把帐号密码配置到jenkins中：
依次点击 凭据 -》 系统 => 全局凭据：
点击左侧添加凭据：
把harbor仓库的账号密码配置一下，得到凭据的唯一ID：
我们可以在pipeline中引入密钥，机制是通过environment环境变量以及一个方法叫做credentials：
https://jenkins.io/doc/book/pipeline/syntax/#environment
所以最终jenkinsfile如下：
pipeline {
agent any
stages {
stage(“下载代码”) {
steps {
echo “下载代码”
checkout([$class: ‘GitSCM’, branches: [[name: ‘*/master’]], doGenerateSubmoduleConfigurations: false, extensions: [[$class: ‘RelativeTargetDirectory’, relativeTargetDir: ‘app_repo’]], submoduleCfg: [], userRemoteConfigs: [[url: “${params.APP_REPO}”]]])
}
}
stage(“构建应用”) {
steps {
echo “构建应用”
sh “cd app_repo && sh build.sh”
sh “cp app_repo/deploy.tar.gz ./”
}
}
stage(“打包镜像”) {
environment {
HARBOR_ACCOUNT = credentials(‘1beb6eaf-4651-48c4-b221-6e430d662807’)
}
steps {
echo “打包镜像”
sh “cp dockerfile-php Dockerfile”
sh “docker login harbor.smzdm.com -u ${HARBOR_ACCOUNT_USR} -p ${HARBOR_ACCOUNT_PSW}”
sh “docker build -t ‘harbor.smzdm.com/smzdm/${currentBuild.projectName}:${currentBuild.id}-${currentBuild.startTimeInMillis}’ .”
}
}
stage(“推送镜像”) {
steps {
echo “推送镜像”
sh “docker push ‘harbor.smzdm.com/smzdm/${currentBuild.projectName}:${currentBuild.id}-${currentBuild.startTimeInMillis}’ ”
sh “docker rmi ‘harbor.smzdm.com/smzdm/${currentBuild.projectName}:${currentBuild.id}-${currentBuild.startTimeInMillis}’ ”
}
}
}
}
引入密钥的变量加上_USR和_PSW后缀就是帐号和密码了，在镜像推送到harbor后我还rmi把本机构建的镜像删除了，免得占用jenkins的磁盘。
harbor中的镜像如下：
这样就没问题了。
其他
高可用
Jenkins master主要就是各种配置不希望丢失，所以安装一个ThinBackup插件（安装报错就取消掉插件镜像加速），做定时的全量配置备份即可。
安装后从系统管理进入：
然后配置定时全量备份：
每10分钟一次，如果jenkinks繁忙则可以延长至15分钟一次。
jenkins数据保存到目录：/data/jenkins/backup ，最多保存3份全量历史，备份会压缩为zip。
全局构建的id号也最好备份一下，丢了怪可惜的。
然后插件也备份一下，方便恢复！
老的备份会被zip压缩，节约空间！
记得把目录创建出来！
定期的把这个目录下的zip文件，拷贝走，备份一下就行！
Jenkins配置本身不是一个常修改的东西，问题不大。
Shell脚本与jenkins
可以把大部分pipeline逻辑写在shell脚本里封装起来，但是测试shell脚本只能访问到pipeline中的env和params，其他的参数想传进来除了给shell脚本传参外，可以使用withEnv{}指令，通过env把更多的变量带到shell里访问。
另外，shell脚本肯定也想往jenkins传递变量，我觉得简单做法就是临时写到一个文件里，后续步骤source命令引进来就好了，不需要依赖额外的插件。
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
1