jenkins freestytle
Posted 潘康宁111
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了jenkins freestytle相关的知识，希望对你有一定的参考价值。
一、jenkins简介
jenkins是一款ci/cd工具，ci/cd流程介绍
ci/cd流程
互联网公司软件的开发和发布是一个持续的过程，
持续集成（continuous intergration）:代码的合并，集成测试，不断持续的来做这个事情，为什么要不断持续的做代码合并、集成测试呢，因为对于一个项目新功能的研发，一个团队很多程序员协同开发，每天开发不同的功能，每天产生大量新的代码文件，其实代码最容易出问题的地方在于代码分支的合并，新功能合并到原有的代码分支上面，多多少少都会出现点冲突兼容性问题，一般代码合并一次集成测试的周期是一天，每天对代码合并集成测试结果进行反馈，尽快发现合并集成方面的问题，如果合并的周期拉的很久一周合并一次，到时候再出现问题，在去追溯修改无疑人力时间进度成本都是巨大的，所以需要强调开发人员做到高频率的合并集成测试，所以这就是持续集成，做的就是代码的合并集成测试，持续集成这一阶段主要保证代码能跑通逻辑没有问题，代码的质量，这都是研发团队干的事情，qa也就是测试在这个环节中并没有介入，等到团队新功能开发的差不多，研发每天的的持续集成也没得问题，研发会提交一个上线申请书，通知QA测试再次校验测试代码的质量和进行代码的功能测试
角色：研发工程师
偏重点：代码质量的保证，尽可能确保代码级别没问题
持续交付（continuous delivery）：release版本的交付，与持续集成相比，持续交付更注重交付物就是可以随时发布上线的release版本，这个阶段是QA测试真正的测试团队进行介入了，对产品进行进一步验证，他们会把研发的新功能开发差不多的代码也就是dev分支拉过来，通过jenkins部署到具体的测试环境中，进行测试，可能首先是进行自动化造数据debug进行代码质量测试，就是一行行代码去验证函数取值返回值对不对等等，对于代码质量的检验比研发做的更细致，其次还会进行功能性的测试，都是图形化的吗，比如模拟一个用户点点功能按钮，看看有没有bug，如果代码质量测试和功能测试有问题bug，提个jira单给开发修改，如果发布新版本比较着急，你这个bug修复时间长或者对现阶段影响不大，就会让你跟下一个版本发布，如果QA测试都没有问题，就会产生一个可交付的产物release分支，这个分支是可以随时发布上线的，此时发邮件给研发，研发准备上线，release分支合并master分支（其实这个release分支里面包含了新功能分支和原master分支，可以随时上线，但是规矩就是上线就得用master），上线方案，通知相关人员做就绪的准备、制定回滚策略等等，运维人员做持续的监控
角色：主要角色是QA测试工程师，研发会做上线的准备
偏重点：可交付的产物，细节检验代码质量，产品代码功能测试，人为用户体验测试
持续部署（continuous deployment）：将代码上线到生产环境，不可能逐步手工的拉代码一台台服务器进行上线，因为持续集成，持续交付都是很频繁的，手动你这个太没有效率了，实际生产环境需要通过运维自动化手段品台比如ansible完成这些频繁交付的软件部署，部署到任意的环境，比如测试环境，预生产环境、生产环境
角色：运维工程师
偏重点：偏自动化部署，就是将交付的产物部署到各个环境中，如果线上出现bug。评估bug，这一般涉及到职责问题的甩锅了，但是一般都是研发的内部锅，运维不接这个锅，如果bug不影响用户使用体验，并且研发修改很快，那么可能修改好再去部署，所以CI/CD讲究的是持续集成，交付，部署这是一种软件生命周期管理的方法论，最常用的工具是jenkins 管道式流水线发布
jenkins vs gitlab
插件丰富：jenkins是一款老牌的ci/cd工具，相比gitlab的ci/cd流程，jenkins更专业，因为内置了很多插件，就像python一样，有很多现成拿来用的库，可以做科学计算，可以做爬虫，可以做系统运维，因为社区开发了很多种这种模块，我们只需要几行代码就可以实现这种需求，jenkins也是一样，功能插件十分丰富，大部分时间不是造轮子，去写这些模块代码，而是jenkins插件十分丰富，各种功能都能实现，gitlab的ci/cd是它内置的功能，插件少功能单一，所以ci/cd这一块跟偏向于jenkins
支持分布式构建：利用更多服务器来完成项目的构建，当你的项目有上百上千的时候，是不是就嘚多台jenkins服务器一起工作了呀
提供API：公司内部开发了一个发布运维系统，发布系统里面可能涉及流水线的编写，这些事情发布运维系统对接jenkins接口的，比如流水线编写调用的就是jenkins的pipline接口，可能自己开发的发布系统就是鼠标点几下就实现了流水线编写，但是背后是调用jenkins的pipline api接口默默在背后实现，因为你自己开发的发布系统不可能自己再去开发一个引擎，肯定是调用jenkins的api接口的
市场大众化：jenkins占据了ci/cd的绝对市场，gitlab占据了代码控制版本管理的绝对市场
二、jenkins安装
开源的软件一般都有两个版本LTS版本和release版本，LTS是永久维护版本，也是官方比较推荐的版本，release版本是近期开发的版本，jenkins是java写的，是个war包，支持的平台也是丰富的，微软，各种linux发行版centos 乌班图，debian，苹果都是支持的，docker对吧，至于安装方式，早期大多是yum安装的，后来就用tomcat安装，把jenkins这个war包放在tomcat网站根目录下就能跑，后期就有了docker部署，建议这些运维系统jenkins，gitlab采用docker部署，因为对于程序业务的迁移是十分方便的，这台机器挂了，重新拉个镜像就能起，重要数据都采用数据卷挂载了，重新挂载一下就行，虚拟机很多环境配置还得重新搞
tomcat安装jenkins
jdk环境安装：jenkins是java写的，java写的程序必须需要jdk环境，jdk本身就是跨平台的，微软，linux任何平台系统都支持兼容，jdk有两种版本，一种是openjdk一种是oracle的jdk，看你们公司用哪种，这两个jdk还是有区别的，openjdk直接yum装就行了，oracle的jdk包从官网下，jdk安装好后，还需要配置系统环境变量/etc/profile，jdk的命令才可以在命令行去直接使用，否则引用完整的绝对路径（/usr/local/jdk/bin目录下都是jdk java相关的二进制文件命令）
maven工具安装：jenkins后续中如果对一些对于java项目代码的编译构建需要maven工具，可以提前准备
1、jdk安装
[root@jenkins ~]# ls
anaconda-ks.cfg jdk1.8.0_45 jdk-8u45-linux-x64.tar.gz
[root@jenkins ~]# mv jdk1.8.0_45 /usr/local/jdk
[root@jenkins ~]# ls /usr/local/jdk
bin db javafx-src.zip lib man release THIRDPARTYLICENSEREADME-JAVAFX.txt
COPYRIGHT include jre LICENSE README.html src.zip THIRDPARTYLICENSEREADME.txt
///usr/local/jdk/bin目录下都是jdk java相关的二进制文件命令
[root@jenkins ~]# ls /usr/local/jdk/bin
appletviewer jarsigner javah jcmd jhat jmc.ini jstat orbd rmiregistry unpack200
ControlPanel java javap jconsole jinfo jps jstatd pack200 schemagen wsgen
extcheck javac javapackager jcontrol jjs jrunscript jvisualvm policytool serialver wsimport
idlj javadoc java-rmi.cgi jdb jmap jsadebugd keytool rmic servertool xjc
jar javafxpackager javaws jdeps jmc jstack native2ascii rmid tnameserv
2、maven安装
[root@jenkins ~]# ls
anaconda-ks.cfg apache-maven-3.5.0 apache-maven-3.5.0-bin.tar.gz apache-tomcat-8.5.59.tar.gz jdk-8u45-linux-x64.tar.gz
[root@jenkins ~]# mv apache-maven-3.5.0 /usr/local/maven
[root@jenkins ~]# ls /usr/local/maven
bin boot conf lib LICENSE NOTICE README.txt
[root@jenkins ~]# ls /usr/local/maven/bin
m2.conf mvn mvn.cmd mvnDebug mvnDebug.cmd mvnyjp
3、配置jdk、maven的二进制文件命令到PATH系统环境变量中
[root@jenkins ~]# vi /etc/profile
[root@jenkins ~]# tail -n 3 /etc/profile
JAVA_HOME=/usr/local/jdk
PATH=$PATH:$JAVA_HOME/bin:/usr/local/maven/bin
export JAVA_HOME PATH
[root@jenkins ~]# source /etc/profile
//jdk,maven的命令直接在命令行就可以用了
[root@jenkins ~]# java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
[root@jenkins ~]# java
java javadoc javah javapackager javaws
javac javafxpackager javap java-rmi.cgi
[root@jenkins ~]# mvn
mvn mvnDebug mvnyjp
4、tomcat安装
[root@jenkins ~]# ls
apache-maven-3.5.0-bin.tar.gz apache-tomcat-8.5.59 apache-tomcat-8.5.59.tar.gz jdk-8u45-linux-x64.tar.gz
[root@jenkins ~]# mv apache-tomcat-8.5.59 /usr/local/tomcat-jenkins
[root@jenkins ~]# cd /usr/local/tomcat-jenkins
[root@jenkins tomcat-jenkins]# ls
bin BUILDING.txt conf CONTRIBUTING.md lib LICENSE logs NOTICE README.md RELEASE-NOTES RUNNING.txt temp webapps work
//webapps是tomcat的默认欢迎页，直接把jenkins的war包直接放在webapps目录下，网站默认工程名是ROOT.war
[root@jenkins tomcat-jenkins]# cd webapps
[root@jenkins webapps]# ls
docs examples host-manager manager ROOT
[root@jenkins webapps]# rm -rf *
[root@jenkins webapps]# rz
[root@jenkins webapps]# ls
jenkins.war
[root@jenkins webapps]# mv jenkins.war ROOT.war
[root@jenkins webapps]# ls
ROOT.war
[root@jenkins webapps]# cd ../bin
[root@jenkins bin]# pwd
/usr/local/tomcat-jenkins/bin
//启动tomcat
[root@jenkins bin]# ./startup.sh
Using CATALINA_BASE: /usr/local/tomcat-jenkins
Using CATALINA_HOME: /usr/local/tomcat-jenkins
Using CATALINA_TMPDIR: /usr/local/tomcat-jenkins/temp
Using JRE_HOME: /usr/local/jdk
Using CLASSPATH: /usr/local/tomcat-jenkins/bin/bootstrap.jar:/usr/local/tomcat-jenkins/bin/tomcat-juli.jar
Using CATALINA_OPTS:
Tomcat started.
//查看一下tomcat的进程
[root@jenkins bin]# ps -ef | grep tomcat
root 17681 1 99 19:52 pts/0 00:00:30 /usr/local/jdk/bin/java -Djava.util.logging.config.file=/usr/local/tomcat-jenkins/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat-jenkins/bin/bootstrap.jar:/usr/local/tomcat-jenkins/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat-jenkins -Dcatalina.home=/usr/local/tomcat-jenkins -Djava.io.tmpdir=/usr/local/tomcat-jenkins/temp org.apache.catalina.startup.Bootstrap start
root 17719 10500 0 19:52 pts/0 00:00:00 grep --color=auto tomcat
[root@jenkins bin]# cd ../
[root@jenkins tomcat-jenkins]# ls
bin BUILDING.txt conf CONTRIBUTING.md lib LICENSE logs NOTICE README.md RELEASE-NOTES RUNNING.txt temp webapps work
[root@jenkins tomcat-jenkins]# less logs/catalina.out
//查看一下tomcat的启动日志，最后输出jenkins已经启动好并且在运行
[root@jenkins tomcat-jenkins]# tail logs/catalina.out -f
09-May-2021 19:52:54.630 信息 [pool-6-thread-4] jenkins.InitReactorRunner$1.onAttained Completed initialization
09-May-2021 19:52:54.701 信息 [Jenkins initialization thread] hudson.WebAppMain$3.run Jenkins is fully up and running
//查看tomcat服务8080端口是否在监听
[root@jenkins tomcat-jenkins]# ss -anput | grep 8080
tcp LISTEN 0 100 :::8080 :::* users:(("java",pid=17681,fd=52))
jenkins已经采用tomcat的形式安装好了
docker安装jenkins
先把tomcat的jenkins停止掉
[root@jenkins tomcat-jenkins]# cd bin
[root@jenkins bin]# ./shutdown.sh
Using CATALINA_BASE: /usr/local/tomcat-jenkins
Using CATALINA_HOME: /usr/local/tomcat-jenkins
Using CATALINA_TMPDIR: /usr/local/tomcat-jenkins/temp
Using JRE_HOME: /usr/local/jdk
Using CLASSPATH: /usr/local/tomcat-jenkins/bin/bootstrap.jar:/usr/local/tomcat-jenkins/bin/tomcat-juli.jar
Using CATALINA_OPTS:
准备jdk环境，maven工具，这台机器已经准备好了，用jenkins镜像docker run启容器即可
//docker安装jenkins
docker run -d --name jenkins -p 8080:8080 -p 50000:50000 -u root \\
-v /opt/jenkins_home:/var/jenkins_home \\
-v /var/run/docker.sock:/var/run/docker.sock \\
-v /usr/bin/docker:/usr/bin/docker \\
-v /usr/local/maven:/usr/local/maven \\
-v /usr/local/jdk:/usr/local/jdk \\
-v /etc/localtime:/etc/localtime \\
--restart=always \\
--name jenkins jenkins/jenkins:lts
备：涉及两个端口和几个数据卷挂载
端口：8080是jenkins的web也就是tomcat的端口，50000是jenkins与工作节点之间的通信也就是分布式构建时候能用到
数据卷：
/var/jenkins_home：jenkins创建的一些项目、job、配置都是以文件形式保存在/var/jenkins_home文件下，jenkins没有内置数据库
/var/run/docker.sock，/usr/bin/docker jenkins里pipline可能涉及dokcer的命令环境，这里挂载到宿主机的dokcer可执行命令下让jenkins本身支持docker命令
/usr/local/jdk，/usr/local/jdk，jenkins可能里面有java的项目，涉及运行构建，挂载本地的jdk，maven
/etc/localtime时区同步宿主机时区
//查看jenkins容器启动状态
[root@jenkins ~]# docker ps -l
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58cf84e7a277 jenkins/jenkins:lts "/sbin/tini -- /usr/…" 19 seconds ago Up 17 seconds 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp jenkins
//docker的网络的实现iptables
首先进站流量通过nat表的docker链类似于prerouting链进行dnat转换，宿主机所有网卡除了docker0网卡8080,50000端口流量都是转换成容器172.17.0.2:8080:50000端口的流量
[root@jenkins ~]# iptables -t nat -vnL DOCKER
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0
0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:50000 to:172.17.0.2:50000
0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:8080
//然后宿主机充当路由器实现路由转发，172流量走172.1路由器网关转发，走的是filter表的forward链，
root@jenkins ~]# ip route
default via 192.168.31.1 dev ens37 proto static metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.10.0/24 dev ens33 proto kernel scope link src 192.168.10.80 metric 100
192.168.31.0/24 dev ens37 proto kernel scope link src 192.168.31.206 metric 100
//这里可以详细看出进出站的规则，最下面两条是进站规则，中间两条是出站规则，出站进行了snat masquerade，最上面是accept接受
[root@jenkins ~]# iptables-save | grep 172.17.0.2
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 50000 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 50000 -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 8080 -j MASQUERADE
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 50000 -j DNAT --to-destination 172.17.0.2:50000
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:8080
配置maven国内源：我们知道yum就是为了解决安装rpm包的依赖而生的命令工具，企业中可能为了软件安装的方便有自己的yum源仓库，比如安装docker就用到一些docker源，k8s就用到一些k8s源，同理maven的话也是需要用到mavne源，但是这些一般都是国外的源，我们要换成国内的源，比如ali，清华的这些国内源源，这样快，maven工具是编译构建java项目的必须的工具，我们也需要换成国内的maven源，这个后续用到再说
三、jenkins基本配置
三个维度，让jenkins ui变的好看些，而是常用插件的安装使用，插件是jenkins的核心精髓，丰富插件用来实现jenkins丰富的功能，最后是设置中文
jenkins的ui定制
安装一个simple插件，每个主题颜色对应的不同的cdn的url，其实就是一个css文件
插件安装好去配置
比如换成cyan这个颜色，url后面就需要加个cyan
https://cdn.rawgit.com/afonsof/jenkins-material-theme/gh-pages/dist/material-cyan.css
现在换成了天蓝色背景
插件在线安装和配置加速
常用插件
jenkins内置的源是国外的源update.jenkins.io这个源，插件都是从default.json这个文件里面的update.jenkins.io这个国外源下载的，我们换成国内清华源去下载加速这些插件，同时把探测google换成百度
[root@jenkins jenkins_home]# cd updates/
[root@jenkins updates]# ls
default.json hudson.tasks.Maven.MavenInstaller
[root@jenkins updates]# pwd
/opt/jenkins_home/updates
[root@jenkins updates]#
sed -i \'s/https:\\/\\/updates.jenkins.io\\/download/https:\\/\\/mirrors.tuna.tsinghua.edu.cn\\/jenkins/g\' default.json && \\sed -i \'s/http:\\/\\/www.google.com/https:\\/\\/www.baidu.com/g\' default.json
大多数人人为了解决插件下载快的问题，都是在jenkins仪表盘这里去改源的地址，实际上那个地址是插件索引的地址，实际下载插件的地址还是default.json里面这个国外源地址，它不改不会快
重启容器生效或者利用restart api重启
插件离线安装
对于一些政企或者学校的网站，服务器是不允许上网的，这个时候插件采用离线包安装的形式，缺点是装一个大的套件不只是一两个插件包的那种，离线包安装就会比较困难
https://mirrors.tuna.tsinghua.edu.cn/jenkins/plugins/ jenkins离线插件包网站
配置中文语言
下载两个插件。locale plugin和chinese
注意;google浏览器不适配jenkins的中文，我们采用火狐浏览器，可看出已经汉化
四、jenkins参数化配置
![image-20210511171252794]
项目管理：搭建好jenkins，怎么去工作，去实现自动化的发布，自动化拉取代码，构建，部署
权限管理：为不同的用户得配不同的的权限
参数化扩展：内置的参数化扩展只能实现简单的，更复杂更针对性的扩展也是必要的
分布式构建：master/slave
拷贝构建文件到远程服务器执行shell命令
项目管理（自由风格）
新建一个任务，针对你的项目进行一个发布，我们从gitlab中拉取一个项目zuul
![image20210511192743743.png]
丢弃旧的构建、内置参数化
新建一个任务，针对你的项目进行一个发布，我们从gitlab中拉取一个项目zuul
采用自由风格和流水线形式是两种不同的工作流，现在的jenkins是纯净的，不装任何插件jenkins的功能是十分简单单一的，但是我们得先熟悉自由风格，后面才能采用流水线风格完成，上面这个界面就是对参数化构建的一些配置，包括自动化拉取代码，自动化构建，自动化部署都是在ms-zuul这个任务面板里面完成
丢弃旧的构建：目的在于对于一个项目清理一些历史的构建，不然永久保存，对于jenkins的磁盘消耗将是巨大的，建议配置，可配可不配
参数化构建：就是配置一些人为的交互，很多时候需要定制一些环境的配置就必须人工选择，比如现在我要部选择拉取哪个代码分支，部署到哪个环境上，部署到多少台服务器上面都是需要进行人为的交互，这个参数化构建就是配置人为交互的地方，最常用的是选择参数化（choice parameter）和输入参数化（string parameter）
比如选择test环境，你选择test值，实际是将这个值赋予这个env变量，变量你肯定是用的呀，后续脚本里面会引用这个变量进行处理的，不然你设置这个变量干啥
接下来这些参数化有了，就得从gitlab拉取源码，对这些动态语言写的源码进行编译构建，部署到测试环境中，简单理一下自动化部署项目流程
自动化部署项目流程
1、拿到项目git地址（权限认证）
2、拉取源代码 clone
3、源码编译构建（往往java、go动态语言的开发的源码都需要编译构建才能部署的，静态语言那就不需要编译构建）
4、构建文件（其实就是一个可部署的包，比如war包，拷贝到远程服务器上进行上线）
5、备份服务器现在正在运行程序文件war包，部署新的程序war包（备份是防止新的程序出问题进行回滚）
6、重启、测试访问配置从gitlab拉取源代码
我们用jenkins并不是让jenkins帮我们执行shell脚本，写一大推脚本，你还不如写个脚本，还好管理，我们使用jenkins目的是尽可能的使用它的插件完成脚本的功能，大大减少写代码脚本的量，从而高效率运维，记住jenkins功能没有不是jenlisn问题，一定是你没有装相关插件，我们装个git插件
我们就得配置jenkins主机的主机域名解析，解析gitlab的域名，
//先配置虚拟机域名解析
[root@jenkins ~]# vi /etc/hosts
[root@jenkins ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.10.60 gitlab.ctnrs.com
//重启网络，重启dokcer，重启jenkins，记住重启网络意味着docker必须重启，所有容器必须重启，需要谨慎执行
[root@jenkins ~]# systemctl restart network
[root@jenkins ~]# systemctl restart docker
[root@jenkins ~]# docker restart jenkins
[root@jenkins ~]# docker logs jenkins -f
[root@jenkins ~]# docker ps -l
其实这里添加主机名是不需要重启网络也可以生效
[root@jenkins ~]# ping gitlab.ctnrs.com
PING gitlab.ctnrs.com (192.168.10.60) 56(84) bytes of data.
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=1 ttl=64 time=3.45 ms
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=2 ttl=64 time=1.40 ms
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=3 ttl=64 time=0.342 ms
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=4 ttl=64 time=0.560 ms
还有认证问题，http方式连接gitlab是需要用户名密码认证的，我们创建一个gitlab的maintainer账号pankangning，添加一个http的连接gitlab的用户认证凭据
我们配置的虚拟机解析域名，但是jenkins是docker部署的，得进入dokcer看一下本地的/etc/hosts文件有没有解析
[root@jenkins opt]# docker exec -it jenkins bash
//容器内部并没有配置本地域名解析，并且ping 不通gitlab.ctnrs.com这个域名
root@cf35ff61e437:/# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2 cf35ff61e437
//把192.168.10.60 gitlab.ctnrs.com这个域名解析加上，就可以ping通了
root@cf35ff61e437:/# echo "192.168.10.60 gitlab.ctnrs.com" >> /etc/hosts
root@cf35ff61e437:/# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2 cf35ff61e437
192.168.10.60 gitlab.ctnrs.com
root@cf35ff61e437:/# ping gitlab.ctnrs.com
PING gitlab.ctnrs.com (192.168.10.60) 56(84) bytes of data.
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=1 ttl=63 time=0.497 ms
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=2 ttl=63 time=0.522 ms
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=3 ttl=63 time=0.421 ms
64 bytes from gitlab.ctnrs.com (192.168.10.60): icmp_seq=4 ttl=63 time=0.483 ms
我们到jinkins服务器上查看一下
///opt/jenkins_home/workspace/这个目录就是默认jenkins拉取源码的位置目录
[root@jenkins ~]# cd /opt/jenkins_home/workspace/
[root@jenkins workspace]# ls
ms-zuul ms-zuul@tmp
[root@jenkins workspace]# cd ms-zuul
[root@jenkins ms-zuul]# ls
index.html login.html pay.py README.md实际开发中，往往会有很多分支，我们可以指定分支去拉，比如拉个dev分支部署到测试环境
//开发新建一个dev分支，准备部署到测试环境去测试
[root@devolp-matching ~]# ls
anaconda-ks.cfg demo portal zuul
[root@devolp-matching ~]# cd zuul
[root@devolp-matching zuul]# ls
index.html login.html pay.py README.md
[root@devolp-matching zuul]# git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/feature
remotes/origin/master
remotes/origin/patch-1
[root@devolp-matching zuul]# git branch dev
[root@devolp-matching zuul]# git branch
dev
* master
[root@devolp-matching zuul]# git checkout dev
切换到分支 \'dev\'
[root@devolp-matching zuul]# ls
index.html login.html pay.py README.md
[root@devolp-matching zuul]# vi login.html
[root@devolp-matching zuul]# vi jiesuan.py
[root@devolp-matching zuul]# ls
index.html jiesuan.py login.html pay.py README.md
[root@devolp-matching zuul]# git add .
[root@devolp-matching zuul]# git status
# 位于分支 dev
# 要提交的变更：
# （使用 "git reset HEAD <file>..." 撤出暂存区）
#
# 新文件： jiesuan.py
#
[root@devolp-matching zuul]# git commit -m \'新增一个结算功能\'
[dev 1e19707] 新增一个结算功能
1 file changed, 1 insertion(+)
create mode 100644 jiesuan.py
[root@devolp-matching zuul]# git log --oneline
1e19707 新增一个结算功能
a3eb4da Merge branch \'feature\' into \'master\'
b2dc0f5 新增一个支付功能
f1d7488 新增登陆页面
3dc6931 Add new file
ce1862f 添加 README.md
[root@devolp-matching zuul]# git push origin dev
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote:
remote: To create a merge request for dev, visit:
remote: http://gitlab.ctnrs.com/microservice/zuul/-/merge_requests/new?merge_request%5Bsource_branch%5D=dev
remote:
To ssh://git@gitlab.ctnrs.com:2222/microservice/zuul.git
* [new branch] dev -> dev
jenkins准备拉测试分支的代码
branch是自定义的变量还有一些常用的内置变量，为什么需要这些常用内置变量呢，变量肯定都是为下一步脚本引用做准备，比如需要备份，需要拿到你是哪个job来命名你备份的文件名，这样备份一下就能看到你是哪个job的对吧
看一下控制台输出我们看下的确拉取的dev分支，构建编号10，构建的是ms-zuul这个job，在master节点构建，workspace是/var/jenkins_home/workspace/ms-zuul这个目录
Started by user 潘康宁
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/ms-zuul
The recommended git tool is: NONE
using credential 50e583df-c1a8-4701-ad51-8b151f55e9c4
> git rev-parse --resolve-git-dir /var/jenkins_home/workspace/ms-zuul/.git # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gitlab.ctnrs.com/microservice/zuul.git # timeout=10
Fetching upstream changes from http://gitlab.ctnrs.com/microservice/zuul.git
> git --version # timeout=10
> git --version # \'git version 2.20.1\'
using GIT_ASKPASS to set credentials gitlab(http基础认证)
> git fetch --tags --force --progress -- http://gitlab.ctnrs.com/microservice/zuul.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse origin/dev^{commit} # timeout=10
Checking out Revision 1e19707e7e10ee690ea38fb2d8b565a12656e8e6 (origin/dev)
> git config core.sparsecheckout # timeout=10
> git checkout -f 1e19707e7e10ee690ea38fb2d8b565a12656e8e6 # timeout=10
Commit message: "新增一个结算功能"
> git rev-list --no-walk 1e19707e7e10ee690ea38fb2d8b565a12656e8e6 # timeout=10
[ms-zuul] $ /bin/sh -xe /tmp/jenkins6210191977057263996.sh
+ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
+ echo dev
dev
+ echo 10
10
+ echo ms-zuul
ms-zuul
+ echo master
master
+ echo /var/jenkins_home/workspace/ms-zuul
/var/jenkins_home/workspace/ms-zuul
+ pwd
/var/jenkins_home/workspace/ms-zuul
+ ls
index.html
jiesuan.py
login.html
pay.py
README.md
Finished: SUCCESS触发器、代码的编译构建
构建：涉及到jenkins的分布式构建，ip addr可以看出是哪个jenkins拉取的gitlab源码，拉去完执行mvn clean编译构建源码，最后scp推送到需要部署的远程服务器上面，这在构建shell里面是可以完成的，但是我们这里是静态的代码，不想java、go写的动态语言代码不需要编译构建，推送的话就是scp可部署的war包到测试环境服务器等等，推送是jenkins是有插件去完成的，我们尽可能的减少shell的编写
构建触发器：基于某些条件自动触发构建操作，自动执行构建shell，比如只要有新代码的提交就会触发构建，依赖的job项目构建触发，比如项目a job执行了构建，项目b job触发紧随其后执行，那么新代码提交或者依赖的job这些就是触发器
触发远程构建基本不用
Build after other projects are built 用的不多，基本没有
Build periodically 定时周期构建，就是类似于crontab周期计划任务，比如每隔一天构建一次，不考虑代码是否更新
实验每一分钟构建一次，分、时、日、月、周
验证代码文件并没更改也会一分钟构建一次
编号11的控制台输出
Started by timer
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/ms-zuul
The recommended git tool is: NONE
using credential 50e583df-c1a8-4701-ad51-8b151f55e9c4
> git rev-parse --resolve-git-dir /var/jenkins_home/workspace/ms-zuul/.git # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gitlab.ctnrs.com/microservice/zuul.git # timeout=10
Fetching upstream changes from http://gitlab.ctnrs.com/microservice/zuul.git
> git --version # timeout=10
> git --version # \'git version 2.20.1\'
using GIT_ASKPASS to set credentials gitlab(http基础认证)
> git fetch --tags --force --progress -- http://gitlab.ctnrs.com/microservice/zuul.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse origin/master^{commit} # timeout=10
Checking out Revision a3eb4dafcd4e4586a7fa4e36fd664472e98e9455 (origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f a3eb4dafcd4e4586a7fa4e36fd664472e98e9455 # timeout=10
Commit message: "Merge branch \'feature\' into \'master\'"
First time build. Skipping changelog.
[ms-zuul] $ /bin/sh -xe /tmp/jenkins2695935081399921943.sh
+ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
+ echo 11
11
+ pwd
/var/jenkins_home/workspace/ms-zuul
+ ls
index.html
login.html
pay.py
README.md
+ cat index.html
hello worldFinished: SUCCESS
编号12构建的控制台输出
Started by timer
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/ms-zuul
The recommended git tool is: NONE
using credential 50e583df-c1a8-4701-ad51-8b151f55e9c4
> git rev-parse --resolve-git-dir /var/jenkins_home/workspace/ms-zuul/.git # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gitlab.ctnrs.com/microservice/zuul.git # timeout=10
Fetching upstream changes from http://gitlab.ctnrs.com/microservice/zuul.git
> git --version # timeout=10
> git --version # \'git version 2.20.1\'
using GIT_ASKPASS to set credentials gitlab(http基础认证)
> git fetch --tags --force --progress -- http://gitlab.ctnrs.com/microservice/zuul.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse origin/master^{commit} # timeout=10
Checking out Revision a3eb4dafcd4e4586a7fa4e36fd664472e98e9455 (origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f a3eb4dafcd4e4586a7fa4e36fd664472e98e9455 # timeout=10
Commit message: "Merge branch \'feature\' into \'master\'"
> git rev-list --no-walk a3eb4dafcd4e4586a7fa4e36fd664472e98e9455 # timeout=10
[ms-zuul] $ /bin/sh -xe /tmp/jenkins5371342353367655412.sh
+ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
+ echo 12
12
+ pwd
/var/jenkins_home/workspace/ms-zuul
+ ls
index.html
login.html
pay.py
README.md
+ cat index.html
hello worldFinished: SUCCESS两次构建代码文件并没有更改单纯从定时周期的角度去构建触发器的
POLL SCM 定时周期扫描代码更新构建，就是定时比如每天，扫描一次代码区，如果代码有更新才会执行触发器构建，没有更新不会构建，这是企业中用的最多的
更新dev分支的 index.html文件，每分钟会扫描，扫描到更新去构建
看一下jenkins，新增构建编号13
看一下13的控制台输出，的确更新了index.html才触发每分钟扫描的构建，接着后续几分钟没有更新，也就没有后续构建
Started by an SCM change
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/ms-zuul
The recommended git tool is: NONE
using credential 50e583df-c1a8-4701-ad51-8b151f55e9c4
> git rev-parse --resolve-git-dir /var/jenkins_home/workspace/ms-zuul/.git # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gitlab.ctnrs.com/microservice/zuul.git # timeout=10
Fetching upstream changes from http://gitlab.ctnrs.com/microservice/zuul.git
> git --version # timeout=10
> git --version # \'git version 2.20.1\'
using GIT_ASKPASS to set credentials gitlab(http基础认证)
> git fetch --tags --force --progress -- http://gitlab.ctnrs.com/microservice/zuul.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse origin/dev^{commit} # timeout=10
Checking out Revision a22dc6fbec246ba80430bd376ee30a1876b884d2 (origin/dev)
> git config core.sparsecheckout # timeout=10
> git checkout -f a22dc6fbec246ba80430bd376ee30a1876b884d2 # timeout=10
Commit message: "Update index.html"
> git rev-list --no-walk 1e19707e7e10ee690ea38fb2d8b565a12656e8e6 # timeout=10
[ms-zuul] $ /bin/sh -xe /tmp/jenkins2501685536270930445.sh
+ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
+ echo 13
13
+ pwd
/var/jenkins_home/workspace/ms-zuul
+ ls
index.html
jiesuan.py
login.html
pay.py
README.md
+ cat index.html
hello world 123456Finished: SUCCESS至此就完成了自动化发布的需求，程序员只需要提交代码或者测试时候针对dev分支合并后周期性扫描就会自动触发构建，然后部署到测试环境，测试人员就可以点击功能测试了周期性的扫描进行触发构建，这种自动化的发布任务构建一般适用于开发环境或者测试环境，
用户权限管理
jenkins可能会有多个人使用，比如开发、测试、运维，比如测试、开发工程师不能对jenkins不能配置的，所以需要设置账号权限，开发、测试人员可能只能对自己的job有管理构建权限，别的job可能看都看不到
1、安装基于角色权限控制插件
2、启用激活基于角色策略
3、创建角色、权限集合
role角色是一组权限的集合，每一个角色都对应不同的一组权限，这里有两个方向配置，全局的角色（global roles）和针对jod的权限（item roles）
全局角色配置
全局角色这里只需配置让用户能登陆进来即可，主要限制的是用户对job也就是项目的访问，全局里面添加一个普通的角色就叫user吧，在全局里面只赋予读取的权限，把所有用户添加到全局user这个角色权限集合中，这样所有用户确保可以登录jenkins并且能读取看到所有的job等等
job项目角色配置
针对用户可以访问的项目进行权限设置，比如开发人员user1负责A-zuul这个项目的开发等等，user2负责ms-zuul这个项目的开发，那么user1是不是只能对A-zuul这个项目job有相应的权限，user2是不是只对ms-zuul这个项目有相应的权限是吧，那么项目的角色其实就是基于正则的权限集合，A- ，ms- 就是表示对A、ms项目job权限的集合，然后把user1、user2分别添加到权限集合也就是角色中既可
A-.* :表示以A开头的项目名
对角色A项目，ms项目进行权限集合配置，A项目可以读取、构建，取消构建，删除这4个权限集合，ms项目少个删除权限，这样后续好验证
至此为止，基于全局的角色（权限集合）、基于项目的角色（权限集合）就配置好了，接下来就是创建用户，把角色绑定到不同的用户上面
4、新建用户、用户绑定角色
新建两个用户user1和user2
user1和user2两个用创建好后，正常是无法访问jenlins的，因为并没有给用户绑定任何角色权限集合
给user1绑定itemA权限，user2绑定itemms权限
5、user1和user2账号权限验证
参数化扩展
前面学了两个参数化，是选择（单选）参数化（choice parameter）和输入参数化（string parameter），但是在实际环境中，特别是微服务架构，一个微服务可能有几百个小的服务，但是大致都是相同的，如果每个服务都创建一个item，势必给运维带来工作量和挑
以上是关于jenkins freestytle的主要内容，如果未能解决你的问题，请参考以下文章