Jenkins持续集成持续部署CI/CD(DI)快速上手
Jenkins简介
Jenkins，原名 Hudson，2011 年改为现在的名字。它是一个开源的实现持续集成的软件工具。
官方网站
jenkins在开发中所处的位置和作用
GitLab安装使用
官方网站：https://about.gitlab.com/
安装所需最小配置
内存至少4G
https://docs.gitlab.cn/jh/install/requirements.html
在ssh下安装
官方安装文档：https://gitlab.cn/install/?version=ce
搭建Jenkins-GitLab-ssh 服务器（已有的克隆一个）
建立分组
虚拟机设置
使用MobaXterm远程登陆
若连接不上，检查网络是否打开
点击 应用程序 - 设置
点击 网络
打开 有线网络
由于克隆的，需要修改新的ip地址
配置一下网络自启
第一步：su 进入root用户
命令：su - root
第二步：进入/etc/sysconfig/network-scripts/
命令：cd /etc/sysconfig/network-scripts/
第三步：查看 是否存在 ifcfg-ens33（可能因服务器而异，名称不一样）
命令是：ls
麒麟服务器可能是ifcfg-enp4s0
第四步：命令vim打开ifcfg-ens33
命令：vim ifcfg-ens33
第五步：把 ONBOOT=no修改为ONBOOT=yes
输入i 进入输入模式，把 ONBOOT=no修改为ONBOOT=yes
第六步：退出并保存
1 安装依赖
# 安装各种依赖
sudo yum install -y curl policycoreutils-python openssh-server perl
# 自启
sudo systemctl enable sshd
# 启动
sudo systemctl start sshd2 配置镜像
curl -fsSL https://packages.gitlab.cn/repository/raw/scripts/setup.sh | /bin/bash3 开始安装GitLab
以下填写自己服务器的ip
sudo EXTERNAL_URL="http://192.168.206.134" yum install -y gitlab-jh安装完成
除非您在安装过程中指定了自定义密码，否则将随机生成一个密码并存储在 /etc/gitlab/initial_root_password 文件中(出于安全原因，24 小时后，此文件会被第一次 gitlab-ctl reconfigure 自动删除，因此若使用随机密码登录，建议安装成功初始登录成功之后，立即修改初始密码）。使用此密码和用户名 root 登录。
gitlab常用命令
gitlab-ctl start # 启动所有 gitlab 组件；
gitlab-ctl stop # 停止所有 gitlab 组件；
gitlab-ctl restart # 重启所有 gitlab 组件；
gitlab-ctl status # 查看服务状态；
gitlab-ctl reconfigure # 启动服务；
vi /etc/gitlab/gitlab.rb # 修改默认的配置文件；
gitlab-ctl tail # 查看日志；在docker下安装
https://docs.gitlab.cn/jh/install/docker.html
安装所需最小配置
-
内存至少4G
-
系统内核至少在3.10以上
uname -r命令可查看系统内核版本
安装docker
- 更新yum源
# 1.备份当前yum源 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup # 2.下载新的CentOS-Base.repo 到/etc/yum.repos.d/ wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo # 或者 curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo # 3.清空并生成缓存 yum clean all yum makecache - 安装yum工具
sudo yum install -y yum-utils device-mapper-persistent-data lvm2 - 配置Docker的yum源
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
sudo sed -i 's+download.docker.com+mirrors.aliyun.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo- 更新yum，建立缓存
sudo yum makecache fast- 安装Docker
yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin- 启动和校验
# 启动Docker
systemctl start docker
# 停止Docker
systemctl stop docker
# 重启
systemctl restart docker
# 设置开机自启
systemctl enable docker
# 执行docker ps命令，如果不报错，说明安装启动成功
docker ps- 配置镜像加速
镜像地址可能会变更，如果失效可以百度找最新的docker镜像。
配置镜像步骤如下：(阿里云各自用各自的，以下仅为参考)
# 创建目录
mkdir -p /etc/docker
# 复制内容
# 2025最新 Docker 国内可用镜像源仓库地址（01月01日更新）
tee /etc/docker/daemon.json <<-'EOF'
{
"registry-mirrors": [
"https://docker.hpcloud.cloud",
"https://docker.m.daocloud.io",
"https://docker.unsee.tech",
"https://docker.1panel.live",
"http://mirrors.ustc.edu.cn",
"https://docker.chenby.cn",
"http://mirror.azure.cn",
"https://dockerpull.org",
"https://dockerhub.icu",
"https://hub.rat.dev",
"https://proxy.1panel.live",
"https://docker.1panel.top",
"https://docker.m.daocloud.io",
"https://docker.1ms.run",
"https://docker.ketches.cn"
]
}
EOF
# 重新加载配置
systemctl daemon-reload
# 重启Docker
systemctl restart docker
# 验证Docker镜像加速是否生效
docker info
# 查看输出信息，如果看到 Registry Mirrors 字段，并且包含了上述镜像地址，则表示配置成功
# 测试
# 添加镜像源后，试着拉取一些热门镜像（如 nginx）来确认配置是否生效：
docker pull nginx使用容器安装gitlab
- 镜像下载
docker pull registry.gitlab.cn/omnibus/gitlab-jh:latest- 创建文件夹
mkdir -p /usr/local/docker/gitlab- 配置环境变量
vim /etc/profile# gitlab基础目录
export GITLAB_HOME=/usr/local/docker/gitlab
- 进入创建的目录
cd /usr/local/docker/gitlab/- 刷新环境变量
source /etc/profile- 重启Docker以重新生成iptables链：
sudo systemctl restart docker- 加载NAT所需的内核模块：
sudo modprobe nf_nat
sudo modprobe xt_nat
sudo modprobe iptable_nat- 重启Docker：
sudo systemctl restart docker- 检查是否存在DOCKER链：
sudo iptables -t nat -L- 如果链不存在，手动创建并重启Docker：
sudo iptables -t nat -N DOCKER
sudo systemctl restart docker- 开放宿主机端口
# 开放端口，重启防火墙
firewall-cmd --zone=public --add-port=880/tcp --permanent
firewall-cmd --zone=public --add-port=222/tcp --permanent
firewall-cmd --zone=public --add-port=8443/tcp --permanent
firewall-cmd --reload
如果报错 FirewallD is not running ，表示防火墙服务（FirewallD）未启动，所以无法执行端口开放命令。需要先启动 FirewallD 服务，再执行端口配置，步骤如下：
# 1. 启动FirewallD服务
systemctl start firewalld
# 2. 设置开机自启（避免重启后服务关闭）
systemctl enable firewalld
# 3. 验证 FirewallD 状态：成功标志：输出中显示 Active: active (running)
systemctl status firewalld
- 创建容器
# --hostname使用自己服务器ip
docker run -d \
--hostname 192.168.206.135 \
-p 880:80 -p 222:22 -p 8443:443 \
--name gitlab \
--restart always \
-v $GITLAB_HOME/config:/etc/gitlab \
-v $GITLAB_HOME/logs:/var/log/gitlab \
-v $GITLAB_HOME/data:/var/opt/gitlab \
--shm-size 256m \
registry.gitlab.cn/omnibus/gitlab-jh:latest- 启动容器
docker start gitlab- 查看 GitLab 容器启动失败日志
1. 直接查看容器日志
# 查看 GitLab 容器实时日志
docker logs -f gitlab
# 查看最近100行日志
docker logs --tail=100 gitlab2. 进入容器内部查看日志文件
# 进入 GitLab 容器
docker exec -it gitlab bash
# 查看关键日志文件
# 主日志
cat /var/log/gitlab/gitlab-rails/production.log
# NGINX 日志
cat /var/log/gitlab/nginx/gitlab_access.log
# Sidekiq 日志
cat /var/log/gitlab/sidekiq/current3. 从宿主机挂载目录查看
# 替换为你的实际 $GITLAB_HOME 路径
ls -l $GITLAB_HOME/logs/
# 例如查看 NGINX 日志
cat $GITLAB_HOME/logs/nginx/gitlab_access.log- 查看已存在的容器
docker ps -a- 进入容器
docker exec -it gitlab /bin/bash访问
当首次运行出现502错误的时候排查两个原因
- 虚拟机内存至少需要4g
- 稍微再等等刷新一下可能就好了
- 成功页面
gitlab启动常见报错：
如果下次重启机器后还是报错502,排查日志报错FATAL: lock file "/var/opt/gitlab/postgresql/.s.PGSQL.5432.lock" already exists HINT: Is another postmaster (PID 354) using socket file "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?
这表示 PostgreSQL 的锁文件已存在，说明上次关闭时没有正常清理，或者有其他进程占用了该 socket。
解决方法：
1. 清理 PostgreSQL 锁文件（最直接）
# 方式1：进入容器清理
docker exec -it gitlab bash
rm -f /var/opt/gitlab/postgresql/.s.PGSQL.5432.lock
exit
docker restart gitlab
# 方式2：宿主机挂载目录清理（替换为你的实际路径）
rm -f $GITLAB_HOME/data/postgresql/.s.PGSQL.5432.lock
docker restart gitlab2. 强制终止残留进程
如果锁文件删除后仍报错，可检查并终止残留的 PostgreSQL 进程：
# 进入容器
docker exec -it gitlab bash
# 查找并杀死 PostgreSQL 进程
pkill -f postmaster
# 退出并重启容器
exit
docker restart gitlab预防建议
1.正常关闭容器：避免直接 kill 容器，使用 docker stop gitlab 让服务优雅退出。
2.增加内存配置：GitLab 对内存要求较高，建议宿主机至少分配 4GB 内存，并可在启动命令中增加内存限制：
docker run -d --memory=4g ...3.定期备份数据：使用 gitlab-backup create 定期备份，避免数据丢失。
管理员账号登录
用户名：root
密码存在下面文件中，登录后需要改密码不然24小时之后会失效
注：容器内目录
cat /etc/gitlab/initial_root_password修改密码
切换中文
F5键刷新，恭喜你！显示中文
Git Lab在客户端提交代码
首次gitlab拉取上传代码时，要配置对应的密钥
idea中有一个springboot的demo项目
添加远程仓库
提交到本地仓库
push
输入GitLab仓库的登录账号密码
已成功提交代码
Jenkins安装
官方文档介绍非常详细
安装需求
机器要求：
256 MB 内存，建议大于 512 MB
10 GB 的硬盘空间（用于 Jenkins 和 Docker 镜像）
需要安装以下软件：
Java 11 ( JRE 或者 JDK 都可以)
Docker （导航到网站顶部的Get Docker链接以访问适合您平台的Docker下载）
克隆一台机器，名称叫Jenkins-server01
安装JDK
因为默认的CentOS仓库可能不包含较新的JDK版本，特别是如果用户使用的是CentOS 7或更早的版本。所以可能需要添加额外的仓库，比如EPEL或者Oracle的官方仓库，但更常见的是使用AdoptOpenJDK或Amazon Corretto的源。
1 卸载旧版本 JDK（可选）
# 查找旧版本
rpm -qa | grep java-1.8
# 卸载（示例）
sudo yum remove -y java-1.8.0-openjdk-devel2 安装 Amazon Corretto 17
步骤 1：添加 Amazon Corretto 仓库
# 下载仓库配置
sudo curl -L -o /etc/yum.repos.d/corretto.repo https://yum.corretto.aws/corretto.repo步骤 2：安装 Corretto 17
sudo yum install -y java-17-amazon-corretto-devel3 验证安装
# 检查 Java 版本
java -version
# 输出应包含类似内容：
# openjdk version "17.0.11" 2024-04-16 LTS
# 或
# openjdk version "17.0.11" 2024-04-16 LTS (Corretto-17.0.11.12.1)4 设置默认 Java 版本（如系统存在多版本）
sudo alternatives --config java
# 按提示选择 JDK 17 的编号5 查看java安装位置
# 方式一
which java
# 方式二
whereis java
# 方式三
readlink -f $(which java)
6 配置环境变量
编辑全局环境变量文件：
sudo vim /etc/profile.d/java.sh # 路径可能因发行版不同，用 `readlink -f $(which java)` 确认
export JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto
export PATH=$JAVA_HOME/bin:$PATH使配置生效：
source /etc/profile.d/java.sh安装Jenkins
请选择对应的jenkins版本，因为jdk和jenkins之间有配套关系,具体参考：
https://www.jenkins.io/doc/book/platform-information/support-policy-java/
官网点击下载:
备用下载：https://mirrors.huaweicloud.com/jenkins/war/
选择LTS版本 通用war包 jenkins.war
本次选择 2.479版本
https://mirrors.huaweicloud.com/jenkins/war/2.479/
将jenkins.war传输到服务器
启动war包
#前台启动
java -jar jenkins.war
#后台启动
nohup java -jar jenkins.war &> jenkinsStart.log &
设置jenkins服务开机自启动(可选)
1.通过chkconfig --list命令列出系统中已安装的服务及其启动状态(CentOS6/7/8 通用)
chkconfig --list
2. 创建启动脚本
在/etc/init.d/目录下（chkconfig 默认识别这个目录的服务脚本），创建Jenkins启动脚本
vi /etc/init.d/jenkins_startup.sh脚本内容如下：
#!/bin/bash
# chkconfig: 2345 80 90
# description: jenkins startup/shutdown/restart script (jenkins.war版)
# 上面两行是chkconfig的核心规范，缺一不可！2345是运行级别，80启动优先级，90关闭优先级
# ======================== 需修改的2处配置 ========================
JENKINS_WAR="/root/jenkins/jenkins.war" # 改成你的jenkins.war实际路径！！！
JENKINS_PORT="8080" # jenkins端口，默认8080，不用改就留着
# =================================================================
# 日志和PID文件路径（自动创建，无需修改）
JENKINS_LOG_DIR="/root/jenkins/logs"
JENKINS_LOG="/root/jenkins/logs/jenkins.log"
JENKINS_PID="/root/jenkins/jenkins.pid"
JAVA_CMD="java -jar"
# 创建日志目录和文件
# 1. 判断日志目录是否存在，不存在则创建，存在则不执行任何操作
if [ ! -d "${JENKINS_LOG_DIR}" ]; then
mkdir -p ${JENKINS_LOG_DIR}
echo "日志目录不存在，已创建：${JENKINS_LOG_DIR}"
fi
# 2. 判断日志文件是否存在，不存在则创建空文件
if [ ! -f "${JENKINS_LOG}" ]; then
touch ${JENKINS_LOG}
echo "日志文件不存在，已创建：${JENKINS_LOG}"
fi
# 3. 判断PID文件是否存在，不存在则创建空文件
if [ ! -f "${JENKINS_PID}" ]; then
touch ${JENKINS_PID}
echo "PID文件不存在，已创建：${JENKINS_PID}"
fi
# 启动函数
start(){
if [ -f $JENKINS_PID ] && ps -ef | grep $(cat $JENKINS_PID) | grep -v grep >/dev/null 2>&1; then
echo "【Jenkins】已经在运行，PID: $(cat $JENKINS_PID)"
exit 0
fi
echo "【Jenkins】正在启动，端口: $JENKINS_PORT..."
nohup $JAVA_CMD $JENKINS_WAR --httpPort=$JENKINS_PORT >> $JENKINS_LOG 2>&1 &
echo $! > $JENKINS_PID
echo "【Jenkins】启动成功，PID: $(cat $JENKINS_PID)"
}
# 停止函数
stop(){
if [ ! -f $JENKINS_PID ] || ! ps -ef | grep $(cat $JENKINS_PID) | grep -v grep >/dev/null 2>&1; then
echo "【Jenkins】未运行"
exit 0
fi
echo "【Jenkins】正在停止..."
kill -9 $(cat $JENKINS_PID) >/dev/null 2>&1
rm -rf $JENKINS_PID
echo "【Jenkins】停止成功"
}
# 重启函数
restart(){
stop
sleep 3
start
}
# 状态查看
status(){
if [ -f $JENKINS_PID ] && ps -ef | grep $(cat $JENKINS_PID) | grep -v grep >/dev/null 2>&1; then
echo "【Jenkins】运行中，PID: $(cat $JENKINS_PID)"
else
echo "【Jenkins】已停止"
fi
}
# 传参执行
case "$1" in
start) start ;;
stop) stop ;;
restart) restart ;;
status) status ;;
*) echo "使用方法: $0 {start|stop|restart|status}" ;;
esac
exit 03. 编辑完脚本后对脚本进行赋权
chmod +x jenkins_startup.sh4. 将脚本添加进清单
# 把脚本添加到chkconfig服务列表
chkconfig --add jenkins_startup.sh
# 设置开机自启（核心命令）
chkconfig jenkins_startup.sh on5. 添加完毕后查看清单
# 查看chkconfig 全部配置
chkconfig --list
# 查看脚本的开机自启状态
chkconfig --list jenkins_startup.sh
至此，完成了Jenkins随操作系统启动自启服务的操作
日常使用命令（启动 / 关闭 / 重启 / 查看状态）：
# 启动jenkins
/etc/init.d/jenkins_startup.sh start
# 关闭jenkins
/etc/init.d/jenkins_startup.sh stop
# 重启jenkins (解决你之前页面卡顿/重启无响应的问题，一键重启)
/etc/init.d/jenkins_startup.sh restart
# 查看运行状态
/etc/init.d/jenkins_startup.sh status
密码保存在 /root/.jenkins/secrets/initialAdminPassword
打开浏览器访问，初始化jenkins（默认为8080端口）
服务器ip地址:8080
等待初始化完成
如果访问不了，可能服务器得开放8080端口，命令如下
# 1、开启防火墙
systemctl start firewalld
# 2、开放指定端口
# 开放8080端口
firewall-cmd --zone=public --add-port=8080/tcp --permanent
# 参数注释：
# –zone=public 作用域，公开的
# –add-port=1935/tcp 添加端口，格式为：端口/通讯协议
# –permanent 永久生效，没有此参数重启后失效
# 3、重启防火墙
firewall-cmd --reload输入密码登录，密码保存在 /root/.jenkins/secrets/initialAdminPassword
密码文件使用后会自动删除
登录成功
点击安装推荐的插件，等待安装完毕，安装失败是因为jenkins插件源是国外源，需要替换为国内的镜像源。
修改插件更新源
Jenkins的插件源主要是在管理界面中配置更新站点URL。默认是国外的源，可能下载速度慢，所以换成国内的镜像源，比如清华大学的或者华为云的。那用户安装的是WAR包，所以可能Jenkins的主目录在用户的家目录下，比如~/.jenkins
接下来，用户需要修改Jenkins的配置文件。通常，更新站点的URL在hudson.model.UpdateCenter.xml文件中，该文件位于Jenkins的主目录下。需要将原来的url替换成国内的镜像源，例如华为的https://mirrors.huaweicloud.com/jenkins/updates/update-center.json。
编辑主目录下的 hudson.model.UpdateCenter.xml 文件：
vim ~/.jenkins/hudson.model.UpdateCenter.xml
将 <url> 标签内的URL替换为国内镜像源：
# 华为源
<url>https://mirrors.huaweicloud.com/jenkins/updates/update-center.json</url>重启Jenkins服务
# 如果以前台进程运行（Ctrl+C终止后重新启动）：
# 查询进程
ps -ef |grep java
# 杀掉jenkins进程
kill -9 [进程id]
# 重启
java -jar jenkins.war --httpPort=8080创建管理员账户
安装完成
Maven安装
官网
下载后复制到Jenkins所在服务器解压缩即可
本次使用的版本：apache-maven-3.8.6-bin.tar.gz
解压文件：
tar -zxvf apache-maven-3.8.6-bin.tar.gz
移动到指定目录
mv apache-maven-3.8.6 /usr/local/maven配置环境变量
sudo vim /etc/profile.d/maven.sh添加以下内容：
# MAVEN_HOME配置自己maven的安装路径
export MAVEN_HOME=/usr/local/maven/apache-maven-3.8.6
export PATH=$MAVEN_HOME/bin:$PATH使配置生效：
source /etc/profile.d/maven.sh验证是否安装成功
mvn -v
# 输出应包含 Maven 版本及 JDK 信息
配置maven的配置文件
修改/usr/local/maven/apache-maven-3.8.6/conf/settings.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!--
| This is the configuration file for Maven. It can be specified at two levels:
|
| 1. User Level. This settings.xml file provides configuration for a single user,
| and is normally provided in ${user.home}/.m2/settings.xml.
|
| NOTE: This location can be overridden with the CLI option:
|
| -s /path/to/user/settings.xml
|
| 2. Global Level. This settings.xml file provides configuration for all Maven
| users on a machine (assuming they're all using the same Maven
| installation). It's normally provided in
| ${maven.conf}/settings.xml.
|
| NOTE: This location can be overridden with the CLI option:
|
| -gs /path/to/global/settings.xml
|
| The sections in this sample file are intended to give you a running start at
| getting the most out of your Maven installation. Where appropriate, the default
| values (values used when the setting is not specified) are provided.
|
|-->
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<localRepository>${user.home}/.m2/repository</localRepository>
<!-- interactiveMode
| This will determine whether maven prompts you when it needs input. If set to false,
| maven will use a sensible default value, perhaps based on some other setting, for
| the parameter in question.
|
| Default: true
<interactiveMode>true</interactiveMode>
-->
<!-- offline
| Determines whether maven should attempt to connect to the network when executing a build.
| This will have an effect on artifact downloads, artifact deployment, and others.
|
| Default: false
<offline>false</offline>
-->
<!-- pluginGroups
| This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
| when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
| "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
|-->
<pluginGroups>
<!-- pluginGroup
| Specifies a further group identifier to use for plugin lookup.
<pluginGroup>com.your.plugins</pluginGroup>
-->
<pluginGroup>org.mortbay.jetty</pluginGroup>
</pluginGroups>
<!-- proxies
| This is a list of proxies which can be used on this machine to connect to the network.
| Unless otherwise specified (by system property or command-line switch), the first proxy
| specification in this list marked as active will be used.
|-->
<proxies>
<!-- proxy
| Specification for one proxy, to be used in connecting to the network.
|
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net|some.host.com</nonProxyHosts>
</proxy>
-->
</proxies>
<!-- servers
| This is a list of authentication profiles, keyed by the server-id used within the system.
| Authentication profiles can be used whenever maven must make a connection to a remote server.
|-->
<servers>
<!-- server
| Specifies the authentication information to use when connecting to a particular server, identified by
| a unique name within the system (referred to by the 'id' attribute below).
|
| NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are
| used together.
|
<server>
<id>deploymentRepo</id>
<username>repouser</username>
<password>repopwd</password>
</server>
-->
<!-- Another sample, using keys to authenticate.
<server>
<id>siteServer</id>
<privateKey>/path/to/private/key</privateKey>
<passphrase>optional; leave empty if not used.</passphrase>
</server>
-->
<server>
<id>releases</id>
<username>ali</username>
<password>ali</password>
</server>
<server>
<id>Snapshots</id>
<username>ali</username>
<password>ali</password>
</server>
</servers>
<!-- mirrors
| This is a list of mirrors to be used in downloading artifacts from remote repositories.
|
| It works like this: a POM may declare a repository to use in resolving certain artifacts.
| However, this repository may have problems with heavy traffic at times, so people have mirrored
| it to several places.
|
| That repository definition will have a unique id, so we can create a mirror reference for that
| repository, to be used as an alternate download site. The mirror site will be the preferred
| server for that repository.
|-->
<mirrors>
<!-- mirror
| Specifies a repository mirror site to use instead of a given repository. The repository that
| this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
| for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
|
<mirror>
<id>mirrorId</id>
<mirrorOf>repositoryId</mirrorOf>
<name>Human Readable Name for this Mirror.</name>
<url>http://my.repository.com/repo/path</url>
</mirror>
-->
<!-- 华为云 -->
<mirror>
<id>huaweicloud</id>
<mirrorOf>central</mirrorOf>
<url>https://repo.huaweicloud.com/repository/maven/</url>
</mirror>
</mirrors>
<!-- profiles
| This is a list of profiles which can be activated in a variety of ways, and which can modify
| the build process. Profiles provided in the settings.xml are intended to provide local machine-
| specific paths and repository locations which allow the build to work in the local environment.
|
| For example, if you have an integration testing plugin - like cactus - that needs to know where
| your Tomcat instance is installed, you can provide a variable here such that the variable is
| dereferenced during the build process to configure the cactus plugin.
|
| As noted above, profiles can be activated in a variety of ways. One way - the activeProfiles
| section of this document (settings.xml) - will be discussed later. Another way essentially
| relies on the detection of a system property, either matching a particular value for the property,
| or merely testing its existence. Profiles can also be activated by JDK version prefix, where a
| value of '1.4' might activate a profile when the build is executed on a JDK version of '1.4.2_07'.
| Finally, the list of active profiles can be specified directly from the command line.
|
| NOTE: For profiles defined in the settings.xml, you are restricted to specifying only artifact
| repositories, plugin repositories, and free-form properties to be used as configuration
| variables for plugins in the POM.
|
|-->
<profiles>
<profile>
<id>development</id>
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
<profile>
<!--this profile will allow snapshots to be searched when activated-->
<id>public-snapshots</id>
<repositories>
<repository>
<id>public-snapshots</id>
<url>http://public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>public-snapshots</id>
<url>http://public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>development</activeProfile>
<activeProfile>public-snapshots</activeProfile>
</activeProfiles>
<!-- activeProfiles
| List of profiles that are active for all builds.
|
<activeProfiles>
<activeProfile>alwaysActiveProfile</activeProfile>
<activeProfile>anotherAlwaysActiveProfile</activeProfile>
</activeProfiles>
-->
</settings>jenkins上安装maven插件
显示出来，安装成功
git安装
yum install git
Jenkins卸载
我们在实际生产使用jenkins的时候 往往会遇到版本兼容问题 ，这时候就会卸载旧的版本，启动新的版本，如果不卸载旧的版本，新的版本就无法启动。
注：此为war包的卸载方式
我们要卸载jenkins 首先我们要弄清楚他的部署方式 有直接用yum安装的、tar包安装的、war包启动的，本次是使用的war包启动的方式
搞清楚了部署方式 那我就可以直接来卸载jenkins了
1、停止jenkins程序
# 查看jenkins进程
ps -ef |grep java
# 杀jenkins进程
kill -9 [jenkins进程id]2、jenkins的安装目录
jenkins使用java -jar 启动的时候会在家目录下面生成隐藏jenkins文件 如下图：
上图里面就是用war包启动的方式生成的jenkins目录
3、卸载jenkins
卸载jenkins的话 我们只需要把jenkins生成的目录文件删除掉就可以了，在启动新的war包即可
Jenkins + Git + Maven 自动化部署配置
新建Item
Git安装配置
git安装
yum install -y git复制仓库地址
Maven配置
Pom.xml配置
如果java-project后边还有目录层级就得加上，如demo1/pom.xml
测试运行流水线
测试运行jar包
# 前提开放端口
# 1、开启防火墙
systemctl start firewalld
# 2、开放指定端口
# 开放8088端口
firewall-cmd --zone=public --add-port=8088/tcp --permanent
# 参数注释：
# –zone=public 作用域，公开的
# –add-port=1935/tcp 添加端口，格式为：端口/通讯协议
# –permanent 永久生效，没有此参数重启后失效
# 3、重启防火墙
firewall-cmd --reload
# 因为jenkins占用了默认的8080端口，启动jar包指定下其他未占用的端口
java -jar DemoApplication-0.0.1-SNAPSHOT.jar --server.port=8088
浏览器访问
和代码一致
创建测试服务器
测试服务器地址 192.168.206.137
publish over ssh 配置
1 安装插件
Manage Jenkins --- Plugins --- Available plugins ---输入 Publish Over SSH
2 全局配置里添加服务器
Manage Jenkins --- System
3 进入项目，在Post Steps里添加目标服务器
source files： 源文件。如果要传输文件夹内所有文件和文件夹则需要在文件夹路径后加两个*符号
Remove Prefix：移除前缀，是指源文件的前缀，比如现在我们只是传输html文件夹里的所有文件，但是html文件夹本身不需要在远程服务器出现，那么就需要将其移除。
Remote directory 远程服务器目录，注意该目录是相对于刚刚全局系统设置里ssh servers里设置的远程路径
exec command 在传输完成后执行的命令，一般为清理文件、复制文件、重启一些服务等等。remote directory : 全局配置文件夹拼接到 代码打包路径
eg:
/user/local/csis/csis-demo = /user/local/csis + /csis-demo
启动流水线，验证测试服务器
超时机制
输出命令时一定要注意不要让窗口卡主，不然Jenkins会认为认为一直没完成
可以在全局配置里设置超时时间
shell的日志输出
解决启动jar包卡住，导致流水线超时
nohup java -jar /root/xxoo/*.jar >mylog.log 2>&1 &
数据流重定向
数据流重定向就是将某个命令执行后应该要出现在屏幕上的数据传输到其他地方
标准输入（stdin）：代码为0，使用<或<<;
标准输出（stdout）：代码为1，使用>或>>;
标准错误输出（stderr）：代码为2，使用2>或2>>
> 覆盖写 >> 追加写
Pre Steps 运行前清理
前置步骤执行停止服务脚本
测试服务器下编写脚本
vi ~/stopServer.sh#!/bin/bash
#删除历史数据(之前的jar包)
rm -rf xxoo
#获取传入的第一个参数
servername=$1
echo "arg:$1"
#获取正在运行的jar包pid
# grep $1 过滤出带有jar包名的进程
# grep 'java -jar' 过滤出java启动jar的进程
# awk '{printf $2}' 只保留筛选出来的进程的第二个参数，即：当前应用进程的id
pid=`ps -ef | grep $1 | grep 'java -jar' | awk '{printf $2}'`
echo $pid
#如果pid为空，提示一下，否则，执行kill命令
if [ -z $pid ];
#使用-z 做空值判断
then
echo "$servername not started"
else
kill -9 $pid
echo "$servername stoping...."
#二次检查，判断是否杀掉，如果pid为空，表示已杀掉，提示一下，否则，再次执行kill命令
check=`ps -ef | grep -w $pid | grep java`
if [ -z $check ];
then
echo "$servername pid:$pid is stop"
else
echo "$servername stop failed"
fi
fi更改脚本执行权限，脚本创建者可执行
chmod 744 stopServer.sh
几种构建方式
-
快照依赖构建/Build whenever a SNAPSHOT dependency is built
-
当依赖的快照被构建时执行本job
-
-
触发远程构建 (例如,使用脚本)
-
远程调用本job的restapi时执行本job
-
-
job依赖构建/Build after other projects are built
-
当依赖的job被构建时执行本job
-
-
定时构建/Build periodically
-
使用cron表达式定时构建本job
-
-
向GitHub提交代码时触发Jenkins自动构建/GitHub hook trigger for GITScm polling
-
Github-WebHook出发时构建本job
-
-
定期检查代码变更/Poll SCM
-
使用cron表达式定时检查代码变更，变更后构建本job
-
示例：以上构建方式以第三种方式（job依赖构建/Build after other projects are built）举例：
新建一个新job,命名为before-first
配置构建步骤 -- 选择Execute shell
在first这个job中配置：
构建触发器 -- 勾选Build after other projects are built -- 输入需要关注的上游job名first -- 选择触发方式 -- 保存 -- 触发构建 before-first这个流水线
当before-first流水线构建完成之后就会调起下游流水线first
1.触发远程构建
在构建触发器中配置接口和token
远程触发构建url:
JENKINS_URL/job/first/build?token=TOKEN_NAME
测试：
浏览器访问:http://192.168.206.136:8080/job/first/build?token=123123
会发现该项目已经触发构建了
存在的问题：
但是如果url在其他没有登录过jenkins的浏览器打开或者使用postman/apifox发送get请求,会提示登录jenkins或者“Authentication required”，需要身份认证，如果把这个地址添加到gitlab中也不会生效。
解决措施：添加插件“Build Authorization Token Root”（启用token后免登录）
官方说明：
测试：
需要使用另外一个url: /buildByToken/build?job=NAME&token=SECRET
http://192.168.206.136:8080/buildByToken/build?job=first&token=123123
调用流水线成功
2.gitlab上代码改动触发构建
代码改动自动可以使用gitlab的webhook回调钩子调起Jenkins的启动任务接口
gitlab对应的项目代码下设置
取消SSL验证(因为gitlab服务使用的普通的http,未使用https模式) --- 添加webhook
添加后可能会有两种报错：
a.提示提供的网址无效
b.提示 “Url is blocked: Requests to the local network are not allowed”，意为 “URI 被拦截：不允许向本地网络发起请求”。
解决措施：
1.打开gitlab --- 管理员 --- 设置 --- 网络 --- 出站请求 ---允许来自 webhooks 和集成对本地网络的请求
2.重新设置Webhooks
3.添加成功
4.测试：点击推送事件
会触发远程构建
此时在idea提交代码到gitlab后，jenkins也会触发构建
3.定时构建
Jenkins cron表达式
标准cron
Jenkins cron不是标准的cron表达式
第一个 * 表示每个小时的第几分钟，取值0~59
5 * * * * 表示每小时的第5分钟
第二颗 * 表示小时，取值0~23
* 15 * * * 表示每天下午3点
* 1 * * * 表示每天凌晨1点第三颗 * 表示一个月的第几天，取值1~31
* 1 5 * * 表示每月5日凌晨1点第四颗 * 表示第几月，取值1~12
* 15 5 1 * 表示每年1月5日15点第五颗 * 表示一周中的第几天，取值0~7，其中0和7代表的都是周日
“/”
表示每隔多长时间，比如 */10 * * * * 表示 每隔10分钟
“H”
hash散列值，以job名取值，获取到以job名为入参的唯一值，相同名称值也相同，这个偏移量会和实际时间相加，获得一个真实的运行时间
意义在于：不同的项目在不同的时间运行，即使配置的值是一样的，比如 都是15 * * * * ，表示每个小时的第15分钟开始执行任务，那么会造成同一时间内在Jenkins中启动很多job，换成H/15 * * * *,那么在首次启动任务时，会有随机值参与进来，有的会在17分钟启动 有的会在19分钟启动，随后的启动时间也是这个值。这样就能错开相同cron值的任务执行了。
H的值也可以设置范围
H * * * *表示一小时内的任意时间
*/10 * * * *每10分钟
H/10 * * * *每10分钟,可能是7,17,27，起始时间hash，步长不变
45 3 * * 1-6 每个周一至周六，凌晨3点45 执行1次
45 3-5 * * 1-6 每个周一至周六，凌晨3点45 ，凌晨4点45，凌晨5点45 各执行1次
H(40-48) 3-5 * * 1-6 在40~48之间取值 其他同上
45 3-5/2 * * 1-6 每个周一至周六，凌晨3点45 ，凌晨5点45 各执行1次
45 0-6/2 * * 1-6 * * 1-6 0点开始，每间隔2小时执行一次 0:45、2:45、4:45
源码变更构建
使用Poll SCM 方式与Build periodically一样
会主动定期检查代码托管服务器上是否有变化，一旦发生变化执行job构建
按照以上设置后，jenkins会每分钟检查gitlab代码，如果代码变动就会调用起流水线
测试报告邮件通知
1.首先要准备两个邮箱，一个发邮件的邮箱、一个收邮件的邮箱，本次示例如下：
发邮件：L******@126.com
收邮件：9******@qq.com
2.配置发送邮件的账号
使用网易126邮箱发送邮件
开启POP3/SMTP服务
新增授权密码
记录下授权密码
JR***********vc
3.jenkins中配置邮件通知
4.在需要邮件通知的流水线中设置
构建流水线first，构建日志结尾会显示发邮件相关的日志
到收邮件的邮箱查看
自动化部署到docker容器中
docker外挂目录
docker run -d -p 8080:8080 --name demo-out -v /root/jarfile/demo-1-0.0.1-SNAPSHOT.jar:/app.jar openjdk:11 java -jar app.jar
-
准备一台测试服务器 docker环境
192.168.206.135
-
准备支持jdk的镜像
FROM openjdk:11 COPY . /usr/src/myapp WORKDIR /usr/src/myapp RUN javac Main.java CMD ["java", "Main"]
-
把jar包打包到容器内
dockerfile
FROM openjdk:11 EXPOSE 8080 WORKDIR /root ADD jarfile/demo*.jar /root/app.jar ENTRYPOINT ["java","-jar","/root/app.jar"]
打包镜像
docker build -t demo .
配置国内镜像
修改/etc/docker/daemon.json文件，没有的话创建一个
写入
{
"registry-mirrors": [
"https://ustc-edu-cn.mirror.aliyuncs.com",
"http://hub-mirror.c.163.com",
"https://registry.aliyuncs.com"
]
}
重启服务
systemctl daemon-reload systemctl restart docker
Jenkins添加节点
节点介绍
jenkins的管理节点(slave)就是用来跑job的服务器，主要是为了减轻jenkins服务器的压力。这个slave可以是web集群中的某一台，slave节点不需要安装jenkins，但是需要安装jdk。
master(jenkins服务器)，通过创建slave(管理节点)可以把创建的job运行在指定的slave上，从而减轻master的压力。
jenkins非常消耗系统资源，尽量不要在jenkins上运行job，可以把job绑定到slave上，这样代码就会下载到slave上，然后在把slave上的代码打包到web服务器中。
Jenkins 运行的主机在逻辑上是 master 节点，下图是主节点和从节点的关系。
准备节点环境
步骤1：Jenkins Master 服务器上安装 SSH Build Agents plugin 插件
步骤 2：创建 known_hosts 文件并添加节点密钥
在 Jenkins Master 服务器上执行：
# 创建 .ssh 目录 (如果不存在)
mkdir -p /root/.ssh
chmod 700 /root/.ssh
# 创建 known_hosts 文件并添加节点公钥
ssh-keyscan -t rsa,ecdsa,ed25519 <节点IP或域名> >> /root/.ssh/known_hosts
# ssh-keyscan -t rsa,ecdsa,ed25519 192.168.206.137 >> /root/.ssh/known_hosts
# 修正权限
chmod 600 /root/.ssh/known_hosts添加节点
(1) Manage Jenkins——Nodes
(2) 新建节点——节点名称随便写——勾选固定节点——创建
(3) 配置节点信息
(4) 保存并启动slave
修改主节点名称
当前使用的jenkins版本是 2.479，官方在这个版本默认的主节点名称为“built-in”，如果想修改为master，可进行以下操作
进入指定页面 Manage Jenkins - Nodes
点击主节点右侧齿轮设置 - 修改标签为“master”
重启jenkins/服务器
验证：两种方式指定节点均生效
Jenkins集群/并发构建
集群化构建可以有效提升构建效率，尤其是团队项目比较多或是子项目比较多的时候，可以并发在多台机器上执行构建。
流水线 pipeline
流水线既能作为任务的本身，也能作为Jenkinsfile
使用流水线可以让我们的任务从ui手动操作，转换为代码化，像docker的dockerfile一样，从shell命令到配置文件，更适合大型项目，可以让团队其他开发者同时参与进来，同时也可以编辑开发Jenkinswebui不能完成的更复杂的构建逻辑，作为开发者可读性也更好。
完整语法
5个必备的组成部分
pipeline：整条流水线 agent：指定执行器 stages：所有阶段 stage：某一阶段，可有多个 steps：阶段内的每一步，可执行命令
测试脚本
基础框架
pipeline {
agent any
stages {
stage('拉取代码') {
steps {
echo '拉取代码完成'
}
}
stage('执行构建') {
steps {
echo '执行构建完成'
}
}
}
post {
always {
echo "完成"
}
failure {
echo "失败"
}
}
}
阶段视图 Stage View
blue ocean可视化界面
全新的流水线控制ui，可重复执行某阶段代码
插件中心搜索blue ocean安装即可
post
流水线完成后可执行的任务
-
always 无论流水线或者阶段的完成状态。
-
changed 只有当流水线或者阶段完成状态与之前不同时。
-
failure 只有当流水线或者阶段状态为"failure"运行。
-
success 只有当流水线或者阶段状态为"success"运行。
-
unstable 只有当流水线或者阶段状态为"unstable"运行。例如：测试失败。
-
aborted 只有当流水线或者阶段状态为"aborted "运行。例如：手动取消。
agent
可以指定执行节点
label 指定运行job的节点标签
any 不指定，由Jenkins分配
pipeline {
agent {
node {
label "jenkins-02"
}
}
stages {
stage('拉取代码') {
steps {
sh """
sleep 10
"""
echo '拉取代码完成'
}
}
stage('执行构建') {
steps {
echo '执行构建完成'
}
}
}
post {
always {
echo "完成"
}
failure {
echo "失败"
}
}
}
pipeline中执行自动化构建
pipeline {
agent any
tools {
maven "maven3"
}
stages {
stage("拉取代码") {
steps {
git branch: 'main', credentialsId: 'gitlab', url: 'http://192.168.44.103/root/java-project.git'
echo '拉取成功'
}
}
stage("执行构建") {
steps {
// sh "mvn --version"
sh """
cd demo-1
mvn clean package
"""
echo '构建完成'
}
}
stage("clean test server"){
steps{
sshPublisher(publishers: [sshPublisherDesc(configName: 'testserver', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: '''rm -rf *
docker stop demo
docker rm demo
docker rmi demo
''', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '/root')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])
}
}
stage("发送jar包到测试服务器") {
steps {
sshPublisher(publishers: [sshPublisherDesc(configName: 'testserver', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: '', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '/jarfile', remoteDirectorySDF: false, removePrefix: 'demo-1/target', sourceFiles: '**/demo*.jar'), sshTransfer(cleanRemote: false, excludes: '', execCommand: '''docker build -t demo .
docker run -d -p 8080:8080 --name demo demo''', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '/', remoteDirectorySDF: false, removePrefix: 'demo-1/docker', sourceFiles: 'demo-1/docker/dockerfile')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])
echo 'jar send over!'
}
}
}
}
声明式流水线
好处
-
更像是在Jenkins web ui中的操作
-
可读性比较高
-
可以使用blue ocean自动生成
-
支持语法检查
坏处
-
代码逻辑能力比脚本式弱，不能完成特别复杂的任务
脚本式流水线
好处
-
更少的代码和弱规范要求
-
更灵活的自定义代码操作
-
不受约束，可以构建特别复杂的工作流和流水线
坏处
-
读写对编程要求比较高
-
比声明式流水线代码更复杂
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
10
0- 0
已为社区贡献2条内容
所有评论(0)