jenkins部署CI/CD
目录
一、CI/CD
1、为什么要 用CI / CD
2、理解持续集成、持续交付、持续部署
1、持续集成
2、持续集成目的在产生以下效益
3、持续交付
4 、持续部署
二、Jenkins CI/CD
1、 Jenkins CI/CD 流程图
2、Jenkins 介绍
1、Jenkins 功能
2、Jenkins 概念
3、Jenkins 目的
4、Jenkins 特性
5、产品发布流程
3、jenkins安装与使用
1、安装java和maven
2、安装jenkins
4、登录jenkins web管理界面
5、Jenkins用户权限管理
1、用户管理背景
2、安装用户管理插件
3、开启插件功能
4、验证用户管理
5、用户权限划分
6、Jenkins 参数化构建
1、参数化构建背景
2、安装插件并使用
3、 数据来源选择文件
三、部署应用Jenkins+Github+Tomcat实战
1、jenkins部署
1、安装插件
2、插件安装过程
3、配置邮箱（可选）
4、配置Jenkins私钥
5、添加后端服务器
6、配置jdk，maven命令，全局配置
7、构建发布任务
2、部署java服务器，做jenkins打包上线
3、回到jenkins页面开始构建任务
四、部署jenkins+gitlab+tomcat实战
1、gitlab本地仓库与远程仓库的配置
2、jenkins服务器的配置
3、web服务器（tomcat）环境清理
4、jenkins项目的创建与配置
5、项目构建
6、排错
五、 Gitlab+jenkins+tomcat+webhook 自动发布
1、jenkins安装插件
2、gitlab配置项目的webhook
3、测试自动发布
4、排错
1、gitlab出现500错误的解决方法
2、在gitlab测试webhook功能的时候出现403
一、CI/CD
1、为什么要 用CI / CD
软件开发的连续方法基于自动执行脚本，以最大限度地减少在开发应用程序时引入错误的可能性。从新代码的开发到部署，它们需要较少的人为干预甚至根本不需要干预。它涉及在每次小迭代中不断构建，测试和部署代码更改，从而减少基于有缺陷或失败的先前版本开发新代码的机会。这种方法有三种主要方法，每种方法都根据最适合您的策略进行应用。
持续集成(Continuous Integration, CI): 代码合并，构建，部署，测试都在一起，不断地执行这个过程，并对结果反馈。
持续交付(Continuous Deployment, CD): 部署到测试环境、预生产环境。
持续部署(Continuous Delivery, CD): 将最终产品发布到生成环境、给用户使用。
2、理解持续集成、持续交付、持续部署
1、持续集成
持续集成（英语：Continuous integration，缩写为 CI），一种软件工程流程，将所有工程师对于软件的工作复本，每天集成数次到共用主线（mainline）上。
这个名称最早由葛来迪·布区（Grady Booch）在他的布区方法中提出，但是他并没有提到要每天集成数次。之后成为极限编程（extreme programming，缩写为XP）的一部分。在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。
持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。
持续集成主要是强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。简单来讲就是：频繁地（一天多次）将代码集成到主干。
2、持续集成目的在产生以下效益
及早发现集成错误且由于修订的内容较小所以易于追踪，这可以节省项目的时间与成本。
避免发布日期的前一分钟发生混乱，当每个人都会尝试为他们所造成的那一点点不兼容的版本做检查。
当单元测试失或发生错误，若开发人员需要在不除错的情况下还原代码库到一个没有问题的状态，只需要放弃一小部分的更改 (因为集成的次数频繁)。
让 "最新" 的程序可保持可用的状态供测试、展示或发布用。
频繁的提交代码会促使开发人员创建模块化，低复杂性的代码。
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
3、持续交付
持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。
它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
4 、持续部署
持续部署（英语：Continuous Deployment，缩写为 CD），是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
有时候，持续部署也与持续交付混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。
持续部署即在持续交付的基础上，把部署到生产环境的过程自动化。
二、Jenkins CI/CD
1、 Jenkins CI/CD 流程图
说明：上线之前先把代码git到版本仓库，然后通过Jenkins 如Java项目通过maven去构建，这是在非容器之前，典型的自动化的一个版本上线流程.(存在环境依赖问题)
如：它的测试环境，预生产环境，测试环境。会存在一定的兼容性问题 （环境之间会有一定的差异）
说明：这里有一个docker harbor 的镜像仓库，通常会把你的环境打包为一个镜像，通过镜像的方式来部署（解决环境依赖问题）。
2、Jenkins 介绍
Jenkins 是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后，项目从Hudson项目独立。
Jenkins 提供了软件开发的持续集成服务。它运行在Servlet容器中（例如Apache Tomcat）。它支持软件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以执行基于Apache Ant和Apache Maven的项目，以及任意的Shell脚本和Windows批处理命令。Jenkins的主要开发者是川口耕介。Jenkins是在MIT许可证下发布的自由软件。
1、Jenkins 功能
持续的软件版本发布/测试项目。
监控外部调用执行的工作。
2、Jenkins 概念
Jenkins是一个功能强大的应用程序，允许持续集成和持续交付项目，无论用的是什么平台。这是一个免费的开源项目，可以处理任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技术。Jenkins是一种软件允许持续集成。
3、Jenkins 目的
持续、自动地构建/测试软件项目。
监控软件开放流程，快速问题定位及处理，提提高开发效率。
4、Jenkins 特性
开源的java语言开发持续集成工具，支持CI，CD。
易于安装部署配置：可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署，可方便web界面配置管理。
消息通知及测试报告：集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知，生成JUnit/TestNG测试报告。
分布式构建：支持Jenkins能够让多台计算机一起构建/测试。
文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
丰富的插件支持:支持扩展插件，你可以开发适合自己团队使用的工具，如git，svn，maven，docker等。
5、产品发布流程
产品设计成型 -> 开发人员开发代码 -> 测试人员测试功能 -> 运维人员发布上线
持续集成（Continuous integration，简称CI）
持续交付（Continuous delivery）
持续部署（continuous deployment）
3、jenkins安装与使用
1、安装java和maven
将jdk的包和maven的包上传到服务器
[root@localhost ~]# ls
anaconda-ks.cfg apache-maven-3.8.1-bin.tar.gz jdk-8u191-linux-x64.tar.gz
[root@localhost ~]# tar zxf jdk-8u191-linux-x64.tar.gz -C /usr/local/
[root@localhost ~]# mv /usr/local/jdk-8u191 /usr/local/java
[root@localhost ~]# tar zxf apache-maven-3.8.1-bin.tar.gz -C /usr/local/java
[root@localhost ~]# mv /usr/local/java/apache-maven /usr/local/java/maven
[root@localhost ~]# vim /etc/profile
JAVA_HOME=/usr/local/java
MAVEN_HOME=/usr/local/java/maven
PATH=$JAVA_HOME/bin:$MAVEN_HOME/bin:$PATH
export JAVA_HOME MAVEN_HOME PATH
[root@localhost ~]# soure /etc/profile
验证java和maven
[root@localhost ~]# java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
[root@localhost ~]# mvn -v
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /usr/local/java/maven
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: /usr/local/java/jre
Default locale: zh_CN, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-693.el7.x86_64", arch: "amd64", family: "unix"
2、安装jenkins
yum安装jenkins
[root@localhost ~]# wget https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat-stable/jenkins-2.235.1-1.1.noarch.rpm
[root@localhost ~]# yum install -y jenkins-2.235.1-1.1.noarch.rpm
jenkins 配置
[root@localhost ~]# rpm -ql jenkins
/etc/init.d/jenkins # 启动文件
/etc/logrotate.d/jenkins # 日志分割配置文件
/etc/sysconfig/jenkins # jenkins主配置文件
/usr/lib/jenkins # 存放war包目录
/usr/lib/jenkins/jenkins.war # war 包
/usr/sbin/rcjenkins # 命令
/var/cache/jenkins # war包解压目录 jenkins网页代码目录
/var/lib/jenkins # jenkins 工作目录
/var/log/jenkins # 日志
修改配置文件
[root@localhost ~]# grep "^[a-Z]" /etc/sysconfig/jenkins
JENKINS_HOME="/var/lib/jenkins" # jenkins工作目录
JENKINS_JAVA_CMD=""
JENKINS_USER="jenkins" # jenkinx启动用户
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
JENKINS_PORT="8080" # 端口
JENKINS_LISTEN_ADDRESS=""
JENKINS_HTTPS_PORT=""
JENKINS_HTTPS_KEYSTORE=""
JENKINS_HTTPS_KEYSTORE_PASSWORD=""
JENKINS_HTTPS_LISTEN_ADDRESS=""
JENKINS_DEBUG_LEVEL="5"
JENKINS_ENABLE_ACCESS_LOG="no"
JENKINS_HANDLER_MAX="100" # 最大连接
JENKINS_HANDLER_IDLE="20"
JENKINS_ARGS=""
首先需要修改一下启动脚本，文件在/etc/init.d/jenkins
因为jenkins的启动脚本默认java路径为：/usr/bin/java
但是我们新安装的java路径并不是在这个，所以我们需要新添加路径。如图下所示：
新路径地址为：/usr/local/java/bin/java
[root@localhost ~]# systemctl daemon-reload
[root@localhost ~]# systemctl start jenkins
以下是第二种安装方式
因为安装了jdk所以直接安装tomcat，将tomcat的压缩包上传到服务器，可以从官网下载，因为我有这个压缩包，所以我直接上传到我的虚拟机
[root@localhost ~]# tar apache-tomcat-8.5.69.tar.gz -C /usr/local/
[root@localhost ~]# mv /usr/local/apache-tomcat /usr/local/tomcat
tomcat的8009端口默认是关闭的，我们需要手动开启
[root@localhost ~]# vim /usr/local/tomcat/conf/server.xml
4、登录jenkins web管理界面
浏览器访问192.168.242.147:8080/jenkins（注意这个路径，直接访问8080端口是访问不到jenkins的），看到下面的界面，在虚拟机上查看对应密码
1、修改/root/.jenkins/updates/default.jso
jenkins 在下载插件之前会先检查网络连接，其会读取这个文件中的网址。默认是：www.google.com
访问谷歌，这就很坑了，服务器网络又不能 FQ，肯定监测失败呀，不得不说jenkins的开发者脑子锈了，所以将图下的google改为www.baidu.com即可，更改完重启服务。
{"connectionCheckUrl":"http://www.baidu.com/","core":{"buildDate":"Dec 02, 2020","name":"core","sha1":"fMwDSSmyX9SkyDzqpqhd2EjOUy4=","sha256":"Du3rKxGjJyastX2ybiYrGSPPQI6EcIuvRx47U0Yu1vE=","url":"https://updates
.......
2、 修改/root/.jenkins/hudson.model.UpdateCenter.xml
该文件为jenkins下载插件的源地址，改地址默认jenkins默认为：https://updates.jenkins.io/update-center.json，就是因为https的问题，此处我们将其改为http即可，之后重启jenkins服务即可。
其他国内备用地址（也可以选择使用）：
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
http://mirror.esuni.jp/jenkins/updates/update-center.json
域名可供选择(根据实际情况)
点击“Start using jenkins”
5、Jenkins用户权限管理
1、用户管理背景
针对开发运维、测试针对不同角色进行不同权限划分，基于插件：
Role-based Authorization Strategy
Authorize Project
2、安装用户管理插件
安装插件：
3、开启插件功能
4、验证用户管理
1、将刚才的授权策略改回原来的
2、开启允许用户注册（全局安全配置）
3、注册一个新用户
4、登录之后默认就是管理员，可以做任何事
5、将授权策略改为Role-based Authorization Strategy，保存
6、刷新刚才登录的用户页面，发现什么权限都没有了
5、用户权限划分
安装 Role-Based Strategy 插件后，系统管理 中多了如图下所示的一个功能，用户权限的划分就是靠他来做的。
1、Manage Roles（管理角色）
Manage Roles：管理角色，相当于针对角色赋予不同权限，然后在将该角色分配给用户。
角色就相当于一个组。其里面又有Global roles（全局）、item roles（项目）、node roles（），来进行不同划分。
Global roles （全局角色）：管理员等高级用户可以创建基于全局的角色
Item roles（项目角色）：针对某个或者某些项目的角色
node roles（节点角色）：节点相关的权限
（1）Global roles
默认是有一个admin用户的，是所有权限都有的，所有权限都是勾选了的。
接下来我们来添加一个角色：zcg
zcg：该角色为全局角色。这个角色需要绑定Overall下面的Read权限，是为了给所有用户绑定最基本的Jenkins访问权限。
注意：如果不给后续用户绑定这个角色，会报错误：用户名 is missing the Overall/Read permission
（2）Project roles
roles to add：表示项目角色
Pattern：是用来做正则匹配的（匹配的内容是Job(项目名)），比如说根据正则匹配到的项目项目角色就都有权限；
接下来新建项目角色，改项目角色一般给其构建、取消、读取、读取空间权限，一般配置这4个即可
demo ：该角色为项目角色。使用正则表达式绑定 “demo.*"，意思是只能操作 demo 开头的项目。
web ：该角色也为项目角色。绑定 "web.*”，意思是只能操作 web 开头的项目。
（3）node roles
node roles（节点角色）：节点相关的权限
roles to add：表示项目角色
Pattern：是用来做正则匹配的（匹配的内容是节点(slave节点）），比如说根据正则匹配到的项目项目角色就都有权限；
我们创建一个全局角色，两个项目角色
保存
2、 创建可登录用户
3、给用户分配角色
demo-1 用户分别绑定 baseRole 全局角色和 demo 项目角色（有删除权限）
web-1 用户分别绑定 baseRole 全局角色和 web 项目角色（没有删除权限）
记得保存
4、创建对应的项目分配登录相关的用户
web-1 用户登录，只能看到 web01（web开头的） 项目
demo-1 用户登录，只能看到 demo01（demo开头的） 项目
5、验证 demo01 用户授权的项目
6、验证 web01 用户授权的项目
6、Jenkins 参数化构建
1、参数化构建背景
如果只是简单的构建，jenkins自己默认的插件可以做，但是如果我们想要在构建过程中有更多功能，比如说：选择性构建、传参、项目指定变量等等其他功能，基础的参数化构建可以实现一些简单功能，但是要想使用更多功能这时候我们就需要借助参数化构建来实现交互的功能。此处我们来借助以下插件来进行实现：
Extended Choice Parameter（更丰富的参数化构建插件）
Git Parameter
2、安装插件并使用
1、跟上面安装插件的步骤一样
2、项目配置
这里这个branch 就相当于给其当做一个变量，然后来为其进行传参
3、构建选择执行shell进行测试
4、参数化配置已经生效
3、 数据来源选择文件
在jenkins所在服务器进行如下操作：
[root@localhost ~]# vim /opt/jenkins.property
web=WEB-1,WEB-2,WEB-3
web 端配置：
文件的路径就是刚才创建的文件的绝对路径，key就是文件中的web
测试
三、部署应用Jenkins+Github+Tomcat实战
jenkins：192.168.242.147
web服务器（tomcat）：192.168.242.148
1、jenkins部署
1、安装插件
需要安装的插件如下：
Maven Integration：jenkins利用Maven编译，打包所需插件
Deploy to container：--支持自动化代码部署到tomcat容器
Git 插件
Publish Over SSH：通过ssh连接
2、插件安装过程
系统管理--->插件管理---->可选插件--->过滤（插件名字）---->勾选--->直接安装。具体方法前文一样（建议在安装Git插件的时候，把过滤出来的Git、Gitlab、Github的相关插件都安装一下，也不需要太长时间）
3、配置邮箱（可选）
Jenkins 系统管理员邮件地址是Jenkins发送邮件通知时的发件人。
使用管理员帐号登录Jenkins，打开系统管理-系统配置：
找到Jenkins Location栏，在系统管理员邮件地址框中输入系统管理员的邮箱
可以看到测试邮件
4、配置Jenkins私钥
jenkins服务器：
[root@localhost ~]# ssh-keygen
[root@localhost ~]# cat .ssh/id_rsa
...
5、添加后端服务器
需要将jenkins的公钥发送给后端服务器，才能实现免密：
jenkins服务器：192.168.242.147
[root@localhost ~]# ssh-copy-id [email protected]
修改完配置一定记得保存，不保存白瞎
6、配置jdk，maven命令，全局配置
虽然Jenkins服务器上，已经安装了JDK和maven工具，但是，还需要在Jenkins服务中，进行配置；这样Jenkins才能自动化的使用两个工具；
必须把自动安装取消了
同样要把自动安装取消掉
修改完后点击保存。 如果有多个jdk和maven需要配置的话，可以点击新增jdk或者新增maven；
7、构建发布任务
GitHub - bingyue/easy-springmvc-maven: A simple demo about how to use maven combine spring mvc,for the blog "Jenkins application" sample
这里是我再github上，找的一个测试的小项目。能进行编译打包
调用maven命令
2、部署java服务器，做jenkins打包上线
java服务器（web服务器tomcat）：192.168.242.148
[root@localhost ~]# ls
apache-tomcat-8.5.69.tar.gz jdk-8u191-linux-x64.tar.gz
[root@localhost ~]# tar zxf jdk-8u191-linux-x64.tar.gz -C /usr/local/
[root@localhost ~]# mv /usr/local/jdk1.8.0_191 /usr/local/java
[root@localhost ~]# mkdir -p /data/application
[root@localhost ~]# tar zxf apache-tomcat-8.5.69.tar.gz -C /data/application
[root@localhost ~]# mv /data/application/apache-tomcat-8.5.69/ /data/application/tomcat
[root@localhost ~]# vim /etc/profile
....在最后插入下面内容
JAVA_HOME=/usr/local/java
TOMCAT_HOME=/data/application/tomcat
PATH=$JAVA_HOME/bin:$TOMCAT_HOME/bin:$PATH
export PATH JAVA_HOME TOMCAT_HOME
[root@localhost ~]# source /etc/profile
[root@localhost ~]# java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
删除tomcat默认发布目录下面的内容:
[root@localhost ~]# rm -rf /data/application/tomcat/webapps/*
创建目录和脚本:
[root@localhost ~]# mkdir /opt/script
[root@localhost ~]# vim /opt/script/app-jenkins.sh
#!/usr/bin/bash
#本脚本适用于jenkins持续集成，实现备份war包到代码更新上线！使用时请注意全局变量。
#================
#Defining variables
export JAVA_HOME=/usr/local/java
webapp_path="/data/application/tomcat/webapps"
tomcat_run="/data/application/tomcat/bin"
updata_path="/data/update/`date +%F-%T`"
backup_path="/data/backup/`date +%F-%T`"
tomcat_pid=`ps -ef | grep tomcat | grep -v grep | awk '{print $2}'`
files_dir="easy-springmvc-maven"
files="easy-springmvc-maven.war"
job_path="/root/upload"
#Preparation environment
echo "Creating related directory"
mkdir -p $updata_path
mkdir -p $backup_path
echo "Move the uploaded war package to the update 2directory"
mv $job_path/$files $updata_path
echo "========================================================="
cd /opt
echo "Backing up java project"
if [ -f $webapp_path/$files ];then
tar czf $backup_path/`date +%F-%H`.tar.gz $webapp_path
if [ $? -ne 0 ];then
echo "打包失败，自动退出"
exit 1
else
echo "Checking if tomcat is started"
if [ -n "$tomcat_pid" ];then
kill -9 $tomcat_pid
if [ $? -ne 0 ];then
echo "tomcat关闭失败，将会自动退出"
exit 2
fi
fi
cd $webapp_path
rm -rf $files && rm -rf $files_dir
cp $updata_path/$files $webapp_path
cd /opt
$tomcat_run/startup.sh
sleep 5
echo "显示tomcat的pid"
echo "`ps -ef | grep tomcat | grep -v grep | awk '{print $2}'`"
echo "tomcat startup"
echo "请手动查看tomcat日志。脚本将会自动退出"
fi
else
echo "Checking if tomcat is started"
if [ -n "$tomcat_pid" ];then
kill -9 $tomcat_pid
if [ $? -ne 0 ];then
echo "tomcat关闭失败，将会自动退出"
exit 2
fi
fi
cp $updata_path/$files $webapp_path
$tomcat_run/startup.sh
sleep 5
echo "显示tomcat的pid"
echo "`ps -ef | grep tomcat | grep -v grep | awk '{print $2}'`"
echo "tomcat startup"
echo "请手动查看tomcat日志。脚本将会自动退出"
[root@localhost ~]# chmod a+x /opt/script/app-jenkins.sh3、回到jenkins页面开始构建任务
多构建几次，看到下图内容，说明构建成功
四、部署jenkins+gitlab+tomcat实战
我们的实验环境没变，还是上面那个实验的jenkins和tomcat服务器，只是将远程仓库github改成了gitlab，这个gitlab是我们自己创建的私服，gitlab的的部署过程也比较长，这里就不写了，可以看之前的gitlab部署文章：Gti版本控制系统Github与Gitlab的使用
实验环境：
jenkins：192.168.242.147
gitlab：192.168.242.145
tomcat：192.168.242.148
1、gitlab本地仓库与远程仓库的配置
因为我们要从gitlab远程仓库拉取文件到本地，所以gitlab服务器上也要下载git（要注意gitlab是远程仓库，git是版本控制系统）
gitlab:192.168.242.145
[root@localhost ~]# yum -y install git
安装之后，添加全局配置（username email）
[root@localhost ~]# git config --global user.name "root"
[root@localhost ~]# git config --global user.email "[email protected]"添加完全局配置后，还需要将root用户的公钥添加到gitlab的SSH密钥配置中
在gitlab中创建一个分支
然后需要将main这个分支的保护机制取消，不然我们只能拉取文件到本地，但是无法将文件推送到main分支。
然后我们在本地将cloud仓库拉取到本地，将项目的拷贝到拉取过来的文件中，接着讲文件推送到main分支
gitlab：192.168.242.145
[root@www ~]# unzip easy-springmvc-maven-master.zip
[root@www ~]# git clone [email protected]:root/cloud.git
[root@www ~]# ls
anaconda-ks.cfg cloud easy-springmvc-maven-master easy-springmvc-maven-master.zip
[root@www ~]# cp -r easy-springmvc-maven-master/* cloud/
同意覆盖文件 y
[root@www ~]# cd cloud
[root@www cloud]# git add .
[root@www cloud]# git commit -m "a"
...
[root@www cloud]# git push -u origin main
...
在gialab远程仓库查看是否推送成功
2、jenkins服务器的配置
jenkins是从gitlab远程仓库拉取数据，所以jenkins服务器也要下载git，并进行相应的全局配置，因为我们的域名是假的，所以要提前关闭ssl，并且jenkins也要做域名解析，
jenkins：192.168.242.147
vim /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.242.145 www.zcg666.com
[root@localhost ~]# git config --global user.name "root"
[root@localhost ~]# git config --global user.email "[email protected]"
[root@localhost ~]# git config --global http.sslVerify "false"
[root@localhost ~]# git config --global http.sslVerify false
[root@localhost ~]# cat /root/.gitconfig
[user]
name = root
email = [email protected]
[http]
sslVerify = false
3、web服务器（tomcat）环境清理
接下来是tomcat服务器环境清理
tomcat：192.18.242.148
[root@localhost ~]# /data/application/tomcat/bin/shutdown.sh
[root@localhost webapps]# cd /data/application/tomcat/webapps/
[root@localhost webapps]# rm -rf easy-springmvc-maven easy-springmvc-maven.war
[root@localhost webapps]# cd /data/
[root@localhost data]# rm -rf backup/ update/4、jenkins项目的创建与配置
接着就可以去jenkins的页面上创建一个项目，进行相关配置
选择丢弃旧版本
源码管理
构建环境
按照上边标记的修改，其他的使用默认就行，修改完记得保存
5、项目构建
然后访问web服务器进一步验证192.168.242.148:8080/easy-springmvc-maven
6、排错
在配置源码管理时，输入了gitlab仓库的https连接出现以下错误：
出现这个错误，可以排查以下几个方面：
1、检查gitlab的仓库是不是公开的
2、检查jenkins服务器和gitlab服务器的域名解析是否一致
3、检查gitlab的配置文件/etc/gitlab/gitlab.rb中的external_url 'https://xxxx'与域名解析中的内容是否一致
4、检查jenkins是否做了gitlab的全局配置和是否关闭ssl
如果没有的话，需要添加，可以直接在配置文件里修改，也可以通过命令
五、 Gitlab+jenkins+tomcat+webhook 自动发布
之前部署了Gitlab的代码托管平台和Jenkins的代码发布平台。通常是开发后的代码先推到Gitlab上管理，然后在Jenkins里通过脚本构建代码发布。这种方式每次在发版的时候，需要人工去执行jenkins上的构建动作，有时显得过于繁琐。于是就想到了Gitlab的Webhook功能，通过Webhook的相关设置，可以实现代码Push后，自动去触发jenkins上的构建动作，这样就不需要人工干预去执行发版操作了。
目的：当我们修改仓库代码，提交的时候，提交完成他会自动触发jenkins，实验项目的自动发布。
如果开发人员修改了代码；（钩子）利用webhook自动去代码仓库（gitlab）获取新的代码，在jenkins上利用maven进行构建；构建完成后发布到web-server（新版本的上线【新版本自动化上线】）
1、jenkins安装插件
插件：Generic Webhook Trigger
安装完成之后开始配置项目，在上面那个实验的基础上做修改
构建触发器：在将更改的代码推送到 GitLab 时自动进行构建。
2、gitlab配置项目的webhook
1、开启允许从 Web 挂钩和服务向本地网络发出请求功能
2、配置项目的webhook
注意：看到200状态码说明设置成功。可以进行测试
然后在jenkins的界面上可以看到左下角的构建队列产生了一个任务
在构建历史中查看控制台输出，可以看到构建成功
3、测试自动发布
说明我们的webhook配置成功，我们进一步验证，修改一下gitlab远程仓库中的代码，让jenkins实现自动构建，构建完成后发布到web-server上
我们修改其中的内容
在jenkins上查看
然后访问web-server，查看是否发生变化
说明我们的实验部署成功，jenkins实现自动构建，并发布到web-server
4、排错
1、gitlab出现500错误的解决方法
在保证所有配置都正确的前提下，在jenkins端进行以下操作:
项目主页---->项目配置---->构建触发器---->高级---->勾选“允许所有分支触发此作业”
注意：勾选保存退出后，再次进入查看会发现没有勾选，此为正常情况。
再回到Gitlab端测试WebHooks服务。
2、在gitlab测试webhook功能的时候出现403，图片如下：
解决方案：下面的步骤都是在jenkins界面中做的
设置匿名用户拥有可读权限
Manage jenkins->Security->Configure Global Security
选择登陆用户可以做任何事，并开启匿名用户具有可读权限
去掉Gitlab enable authentication 点选 放开
系统管理 -> 系统设置 -> Enable authentication for '/project' end-point
总结
实验一：Gitlab+jenkins+web-server（tomcat）
更换了存放项目的仓库 gitlab 私有仓库（本地） 源码的下载速度也会提升
gitlab正常使用，gitlab仓库， cloud 项目上传到仓库
注意：在提交代码
有git命令，安装git，添加全局配置（username email）
git config --global user.email "[email protected]"
git config --global user.name "xingdian"
取消gitlab中cloud的仓库main分支的保护（能够向main这个分支提交代码）
如果使用域名做本地解析，在gitlab添加提交服务器的公钥
git clone [email protected]:xingdian/cloud.git
将项目压缩包上传到服务器 .zip 解压 并把解压后的内容拷贝到仓库目录下
git提交代码到cloud仓库 main分支
项目上传到仓库（操作）
更换成gitlab仓库地址
去掉gitlab的认证
实验二：GitHub+jenkins+web-server（tomcat） 构建的时候 网络连接超时（正常现象） githud仓库地址
1.安装对应的插件（jenkins）
Deploy to container
Git （插件比较多）
Maven Integration
Publish Over SSH
2.配置ssh
添加jenkins的私钥到key的位置
配置web-server的相关信息（name，ip地址，用户，目录）
jenkins---> web-server 免密
3.全局配置 git maven jdk 相关配置
4.创建任务
实验三：Gitlab+jenkins+web-server（tomcat）+webhook 自动发布
当我们修改仓库代码，提交的时候，提交完成他会自动触发jenkins，实验项目的自动发布
如果开发人员修改了代码；（钩子）利用webhook自动去代码仓库（gitlab）获取新的代码，在jenkins上利用maven进行构建；
构建完成后发布到web-server（新版本的上线【新版本自动化上线】）
1.jenkins
安装插件（Generic Webhook Trigger）
配置项目（上午cloud项目，在这个基础上做的修改）
在构建触发器：
在将更改推送到 GitLab 时进行构建。GitLab webhook URL： http://192.168.222.129:8080/jenkins/project/cloud
保证（gitlab的）webhook能够连接jenkins
配置 ---> gitlab /project 对勾去掉
全局安全配置 ----> 保证登录用户可以做任何事情（匿名用户具有可读权限）
2.gitlab
开启本地网络访问权限（目录：webhook能够连接jenkins）
menu ---> admin --->设置 --->网络 ----> 出站请求 允许即可
配置项目的webhook
项目cloud--->设置--->webhook (添加) 网址 ：http://192.168.222.129:8080/jenkins/project/cloud （图见笔记） ---> 测试 200 ok
3.gitlab（模拟项目代码的更新提交）
项目cloud ---> src/main/webapp/index.jsp ---> 修改完后记得提交 （观察jenkins对应的项目） 等待一段时候后，浏览器访问web-server