centos7中jenkins的安装与配置(超详细)

centos7中jenkins的安装与配置(超详细))

m0_58943936

4934人浏览 · 2024-01-03 17:12:11

m0_58943936 · 2024-01-03 17:12:11 发布

Jenkins官网：https://jenkins.io/ 或 https://www.jenkins.io/zh/download/
Jenkins官网文档：https://www.jenkins.io/zh/doc/
jenkins安装包：http://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat/
jenkins插件库: https://plugins.jenkins.io/
清华镜像：http://updates.jenkins-ci.org/download/war/

准备工作：java环境和maven (可以看我Java开发环境部署中的对应文章)
maven:
https://blog.csdn.net/m0_58943936/article/details/134942539
jdk:
https://blog.csdn.net/m0_58943936/article/details/134604149

(我安装的jenkins需要jdk11版本以上, 所以需要安装对应的jdk版本)
(旧版本支持jdk8版本的我试过 , git,ssh插件一直安装不上,从插件库导入也匹配不上, 就放弃了, 使用了新版本)

需要Java环境
需要maven
需要git

一：jenkins安装

1.官网下载Jenkins war包

我们选择2.426.1, 下载后, 上传到服务器

2.使用命令启动(端口号自行设置开放)

本文章(6模块)启动脚本实现开机自启动jenkins , 可以在jenkins成功后, 自行了解配置)

(进入jenkins.war包所在目录, 使用命令启动)

nohup java -jar jenkins.war --httpPort=16060 &

可以用如下限制Jenkins占用内存

-server -Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m

3.浏览器打开http://你的服务器ip:16060/

注意： 配置安全组或者防火墙的记得放开端口16060，不然搜不到

4. 查看初始化密码(复制后填写到页面的管理员密码中)

cat /root/.jenkins/secrets/initialAdminPassword

5.启动如下

①：选择安装推荐的插件或者选择插件来安装
除非你非常明确的知道自己需要哪几种插件，不然就安装推荐的插件
(如果安装失败也别慌, 进入系统管理-> 插件管理中可以自行安装/或卸载对应插件)

输入用户名密码邮箱

配置访问地址(默认即可,也可按需更改)：

点击开始使用jenkins 就可以使用jenkins了

二：插件

①：Git Parameter git参数
②：Localization: Chinese (Simplified) 简体中文包
③：SSH server ssh服务器
④：Build With Parameters 输入框式的参数(可选)
⑤：Persistent Parameter 下拉框式的参数(可选)
⑥：SSH ssh配置
⑦：Publish Over SSH 通过SSH发送构建好的jar包或war包
⑧：Role-based Authorization Strategy (可选用户权限)

插件安装方法

进入Plugins

进入安装插件 Installed plugins

输入对应插件安装即可

①④⑤在购机按的项目General里面：

③⑥⑦在系统管理-系统配置里面
③：SSH server
⑥：SSH
⑦：Publish Over SSH

⑦：Publish Over SSH 配置好以后也在构建好的项目-构建后操作里面配置内容
(用于通过SSH发送构建好的jar包或war包到配置的服务器上)

三：配置

①：配置国内的清华镜像源

https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
入口：系统管理-插件管理-高级

②：配置maven

入口：系统管理-全局工具配置-maven配置/以及最下面的maven安装
参照我Java开发环境部署中的maven文章, 配置好maven
https://blog.csdn.net/m0_58943936/article/details/134942539
注意: (settings.xml替换为服务器maven的settings.xml路径)

注意: (MAVEN_HOME替换为服务器maven所在路径)

③：配置jdk

参照我Java开发环境部署中的jdk文章, 配置好jdk：https://blog.csdn.net/m0_58943936/article/details/134604149
注意: (JAVA_HOME替换为服务器jdk所在路径)

④：配置git

服务器安装git

yum -y install git

查看git路径

which git

显示路径为/usr/bin/git

⑤：配置凭据参数

入口：

点击System进入全局凭据

进入System后,(如果没有,自行创建一个)

进入后点击添加

添加凭据
(我这里是添加了2个 ,第三个B服务器用户名密码信息的凭据最后发现没用上,ssh那里是直接输入用户名密码)

gitlab-Token用于jenkins系统设置中GitLab的ApiToken绑定

gitlab_user用于jenkins项目管理中的原码管理那里添加用户名密码

⑥：使用API token 连接GitLab的配置

1. GitLab 端生成API Token

登录GitLab -> 在用户头像下拉框，选择“Setting” -> 点击“Access Tokens”，
输入“Name”和“Expires at”，勾选“api” -> 点击“Create personal access token”，
生成access token，记录下此token。

2.Jenkins 端配置GitLab API Token

“Dashboard” -> “Manage Jenkins” -> “System” -> “GitLab”

⑦：配置Publish over SSH

1.查看公钥/私钥

.ssh 文件夹是用于存储用户的 SSH 配置和身份验证信息的目录
进入/root/.ssh目录，看看里面有没有公钥和私钥
如没有

## 创建ssh key 
ssh-keygen -t rsa
## 一路回车

查看/root/.ssh/文件夹目录

cd /root/.ssh/

查看ssh key 私钥/公钥

cat /root/.ssh/id_rsa
cat /root/.ssh/id_rsa_pub

注意：

id_rsa 私钥
id_rsa_pub 公钥
authorized_keys
文件包含一组授权的公钥，用于远程用户的身份验证。当你使用公钥-私钥对进行 SSH 连接时，远程服务>器会验证连接请求中的公钥是否与 authorized_keys 中的某个公钥匹配。
如果匹配成功，用户就被授权登录。每个用户在其主目录下的 .ssh 文件夹中都有一个 authorized_keys 文件。
known_hosts
文件包含已知的主机密钥（公钥），用于验证你连接的远程主机的身份。当你首次连接到一个新的 SSH 服务器时，其公钥将被添加到你的 known_hosts 文件中。
以后的连接将会比较远程主机的公钥是否与 known_hosts 中的匹配，以确保你连接到的是你预期的主机。

⑧：配置SSH Server

四：项目构建

1. 后端

新建一个项目

①：General

进行配置

②：源码管理

③：构建触发器不做任何配置略过

④：构建环境不做任何配置略过

⑤：构建

配置Maven相关内容

解释下这段clean -Dmaven.test.skip=true package -Ptest

clean:

clean 是 Maven 的一个目标（goal），用于清理目标文件夹（通常是 target 文件夹），删除之前构建生成的文件。
-Dmaven.test.skip=true:

-D 是 Maven 命令行中用于传递系统属性的标志。在这里，maven.test.skip 是一个系统属性，设置为 true。
这个选项的作用是跳过执行测试。当设置为 true 时，Maven 将不会执行项目中的测试用例。这在一些构建场景中，特别是快速构建和部署时，可以加快构建过程。
package:

package 是 Maven 的一个构建阶段（phase）。它负责将项目的源代码编译、运行测试，并将构建结果打包成可分发的格式，如 JAR 或 WAR 文件。
-Ptest:

-P 是 Maven 命令行中用于激活构建配置文件中的 Maven Profile 的标志。在这里，test 是要激活的 Maven Profile。
Maven Profile 可以包含一组配置，用于在不同的构建环境或条件下执行不同的构建操作。
例如，在测试环境中使用-Ptest , 生产环境使用-Pprod, 开发环境使用-pdev

综合起来，这个 Maven 命令的作用是清理项目，跳过测试阶段，执行打包阶段，并激活名为 test 的 Maven Profile。这样的命令通常用于在构建过程中定制一些行为，例如在测试环境中构建项目，跳过测试用例的执行，加快构建速度。

ssh命令内容 (具体内容可以看本章内容五模块 )

⑥：构建后操作

注意:

(我一开始使用的这个构建后操作) , 构建项目后将从git拉取的jar包, 复制到B服务器设置的目录中)

(后面发现并不方便, 就写了上面的ssh命令, 代替了这个构建后的操作) ,也就是吧这个构建后操作这一步直接关掉了, 因为和 Execute shell里的命令冲突了

Source files也是一个小坑, 使用的是jenkins工作空间所在的项目路径, 不是A服务器jar包所在路径

五：Execute shell 中的ssh命令

1.查看和修改本地主机名与 IP 地址的映射关系

jenkins的Dashboard -> Manage Jenkins -> System 中的Publish over SSH中的SSH Servers
我们设置了B服务器的别名和连接信息(j也就是Jenkins从git获取内容构建项目成功后将jar包发送到B服务器并在B服务器运行jar包),
所以我们需要在两台服务器做一个别名的映射和互通操作(使用sh不需要密码即可互相连接)

问题1:(没有设置映射,导致找不到test-sever)

1.查看映射关系

通过编辑 /etc/hosts 文件来查看和修改本地主机名与 IP 地址的映射关系
使用 cat 命令查看整个文件cat /etc/hosts
如果信息太多,使用 grep 命令查找特定信息，例如查找是否包含某个主机名
grep "test-server" /etc/hosts

备注:

查看 /etc/hosts 文件需要足够的权限，因此可能需要使用 sudo 或其他管理员权限执行这些命令

上述命令中，如果 /etc/hosts 文件包含 test-server 的映射关系，将显示相应的行。

如果没有包含test-server的映射关系, 则需要我们自行添加

2. 修改本地主机名与 IP 地址的映射关系

打开 /etc/hosts 文件，使用文本编辑器（如 vi 或 vim）进行编辑。在文件的末尾添加类似以下的行后进行保存退出
两台服务器都需要添加test-server的映射, 服务器ip地址都写B服务器的IP, 名称都写自定义的test-server
<服务器IP地址> test-server

备注:

修改 /etc/hosts 文件可能需要管理员权限。你可以使用 sudo 或其他管理员权限来编辑文件。例如：

sudo vim /etc/hosts

test-server为 jenkins的SSH server 中Name自定义的名称
两台服务器都需要添加test-server的映射, 服务器ip地址都写B服务器的IP, 名称都写自定义的test-server

3. 测试是否成功解析

两台服务器执行,如果能够正确解析, 说明更改已经生效
ping test-server

2.查看公钥/私钥

.ssh 文件夹是用于存储用户的 SSH 配置和身份验证信息的目录
进入/root/.ssh目录，看看里面有没有公钥和私钥
如没有

## 创建ssh key 
ssh-keygen -t rsa
## 一路回车

查看/root/.ssh/文件夹目录

cd /root/.ssh/

查看ssh key 私钥/公钥

cat /root/.ssh/id_rsa
cat /root/.ssh/id_rsa_pub

注意：

id_rsa 私钥
id_rsa_pub 公钥
authorized_keys
文件包含一组授权的公钥，用于远程用户的身份验证。当你使用公钥-私钥对进行 SSH 连接时，远程服务器会验证连接请求中的公钥是否与 authorized_keys 中的某个公钥匹配。
如果匹配成功，用户就被授权登录。每个用户在其主目录下的 .ssh 文件夹中都有一个 authorized_keys 文件。
known_hosts
文件包含已知的主机密钥（公钥），用于验证你连接的远程主机的身份。当你首次连接到一个新的 SSH 服务器时，其公钥将被添加到你的 known_hosts 文件中。
以后的连接将会比较远程主机的公钥是否与 known_hosts 中的匹配，以确保你连接到的是你预期的主机。

3.两台机器实现互相通信

互相通信后使用ssh连接不需要使用密码即可连接

问题2(没有设置互通,导致还需要输入密码, 提示权限被拒绝 )

1 服务器 A 和服务器 B 之间建立通信

确保服务器 A 和服务器 B 上都安装了 SSH：

在大多数 Linux 系统中，SSH 已经默认安装。你可以通过以下命令检查：

ssh -V

获取服务器 A 的公钥：在服务器 A 上执行以下命令获取公钥：

cat ~/.ssh/id_rsa.pub

如果使用的是不同的密钥文件，请替换 id_rsa.pub 为你的实际公钥文件名。

将服务器 A 的公钥添加到服务器 B 的 authorized_keys 文件中：

复制服务器 A 上的公钥内容。
在服务器 B 上执行以下命令，将公钥添加到 ~/.ssh/authorized_keys 文件中：
会发现authorized_keys中有两个ssh-rsa,一个是服务器B的, 一个是服务器A的

mkdir -p ~/.ssh     # 如果 .ssh 文件夹不存在则执行创建
echo "粘贴从服务器 A 复制的公钥内容" >> ~/.ssh/authorized_keys
--更改权限(后面两句)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

测试连接：

在服务器 A 上执行以下命令测试连接到服务器 B (不输入密码就能连接上, 代表成功)

ssh username@serverB_IP

替换 username 为服务器 B 上的用户名，serverB_IP 为服务器 B 的 IP 地址或主机名。如果一切设置正确，你应该能够通过 SSH 连接到服务器 B，而不需要输入密码。

可选：设置服务器 B 到服务器 A 的连接：
如果你也想要从服务器 B 连接到服务器 A，重复上述步骤，将服务器 B 的公钥添加到服务器 A 的 authorized_keys 文件中。
现在，你的两台 Linux 服务器应该能够通过 SSH 协议互相通信，实现安全的远程连接。

4.ssh执行命令

1.jenkins部署后的操作将jar传入目标服务器并且运行jar包执行命令

ssh test-server "pkill -9 -f test-admin.jar" || true
ssh test-server "pkill -9 -f test-gateway.jar"  || true
ssh test-server "pkill -9 -f test-business.jar" || true
ssh test-server "pkill -9 -f test-job.jar" || true

ssh test-server "rm -rf /home/workspace/*"
scp -r  ${WORKSPACE}/admin/target/admin.jar test-server:/home/workspace/test-admin.jar
scp -r  ${WORKSPACE}/business/target/business.jar test-server:/home/workspace/test-business.jar
scp -r  ${WORKSPACE}/gateway/target/gateway.jar test-server:/home/workspace/test-gateway.jar
scp -r  ${WORKSPACE}/job/target/job.jar test-server:/home/workspace/test-job.jar

ssh test-server "cd /home/sh && sh start-test-admin.sh"
ssh test-server "cd /home/sh && sh start-test-business.sh"
ssh test-server "cd /home/sh && sh start-test-gateway.sh"
ssh test-server "cd /home/sh && sh start-test-job.sh"

命令解析:

停止正在运行的进程：

ssh test-server “pkill -9 -f chain-authorization.jar” || true：
通过 SSH 连接到 test-server 主机，使用 pkill 命令强制终止所有包含字符串 “test-admin.jar” 的进程。|| true 部分表示如果命令执行失败（例如没有找到匹配的进程），也继续执行下一步。

类似地，停止其他三个进程（gateway , business, job）。

删除目录内容：

**ssh test-server "rm -rf /opt/chain-test/"：
通过 SSH 连接到test-server 主机，使用 rm -rf 命令递归地删除/home/workspace/ 目录下的所有文件和子目录。

复制 JAR 文件到远程主机：

scp -r ${WORKSPACE}/admin/target/admin.jar test-server:/home/workspace/test-admin.jar:
使用 scp 将本地 **${WORKSPACE}/admin/target/admin.jar **文件复制到 test-server 主机的 /home/workspace/ 目录，并将其命名为 test-admin.jar。

类似地，复制其他三个 JAR 文件到 **test-server **主机的相应目录。

启动新的进程：

ssh test-server “cd /home/sh && sh start-test-admin.sh”
通过 SSH 连接到 test-server 主机，切换到**/home/sh** 目录，然后执行 start-test-admin.sh 脚本，启动 test-admin.jar 进程。

类似地，启动其他三个进程（gateway , business, job）

整体而言，这个脚本的目的是在远程主机上更新和重新启动一组 Java 进程，其中包括 admin , gateway , business, job 进程。

2. sh脚本运行jar包及生成日志

#!/bin/bash
BUILD_ID=dontKillMe
cd /home/workspace/
nohup /home/soft/jdk/jdk-11.0.20/bin/java -Xms128m -Xmx512m -Dproject.name="admin" -jar test-admin.jar > admin.log 2>&1 &
-- 备注:后面jar包的sh脚本是相同的,如果jar包存放位置在一个目录,更改jar名称和日志名称即可

#!/bin/bash
BUILD_ID=dontKillMe
cd /home/workspace/
nohup /home/soft/jdk/jdk-11.0.20/bin/java -Xms128m -Xmx512m -Dproject.name="business" -jar test-business.jar > business.log 2>&1 &

3.配置好后进入项目,进行构建

构建成功后,查看控制台输出

项目构建完成(下方是构建输出结果)

六.使用启动脚本实现开机自启动jenkins

在Linux系统上，可以通过创建一个启动脚本并将其添加到系统的启动服务中来实现Jenkins的开机自启动。下面是一个简单的Jenkins启动脚本的例子，你可以根据实际情况进行调整。

创建启动脚本并使用脚本启动服务

创建Jenkins启动脚本：

使用文本编辑器创建一个启动脚本，比如 jenkins_start.sh
(建议在jenkins.war包所在目录下创建该启动脚本)

#!/bin/bash

JENKINS_HOME="/path/to/your/jenkins/home"
JENKINS_WAR="/path/to/your/jenkins.war"
JENKINS_PORT=16060(自己开放的jenkins端口)

nohup java -jar $JENKINS_WAR --httpPort=$JENKINS_PORT --webroot=$JENKINS_HOME/war > $JENKINS_HOME/jenkins.log 2>&1 &

请确保替换上述脚本中的 /path/to/your/jenkins/home 和 /path/to/your/jenkins.war 为你的实际Jenkins主目录和Jenkins.war文件的路径。

添加执行权限：

使用以下命令为脚本添加执行权限：

chmod +x jenkins_start.sh

配置Jenkins开机自启动：

如果你使用的是 Systemd（通常在现在 Linux 发行版上），可以创建一个 Systemd 服务单元文件。创建文件 /etc/systemd/system/jenkins.service，并在其中添加以下内容：

[Unit]
Description=JenkinsServer

[Service]
ExecStart=/path/to/jenkins_start.sh
User=your_jenkins_user(一般是root)
Restart=always

[Install]
WantedBy=multi-user.target

替换 /path/to/jenkins_start.sh 为你实际的脚本路径，将 your_jenkins_user 替换为运行Jenkins的用户。

Restart=always：
这个选项指定了服务在退出时应该如何重启。
always 表示无论服务以何种方式退出（正常退出、崩溃等），都应该尝试重新启动服务。
这有助于确保Jenkins服务在发生意外故障时能够尽快恢复。

WantedBy=multi-user.target：
这个选项指定了服务应该由哪个目标（target）启动。
在Systemd中，target 是一组单元的集合，代表了系统的一个状态。multi-user.target 通常表示多用户模式，是一个用户登录后的标准系统状态。
当你启动系统时，Systemd会尝试启动 multi-user.target，从而启动与之相关联的所有服务，包括 Jenkins。
通过将 WantedBy 设置为 multi-user.target，你告诉Systemd在多用户模式下启动时自动启动Jenkins服务。

综合起来，这两个选项确保了Jenkins服务会在系统启动时自动启动，并且在发生故障时会尝试重新启动。这是在生产环境中保持服务稳定性和可用性的重要配置

如果你使用 SysV init（较旧的 Linux 发行版可能使用），可以将启动脚本添加到启动目录中：

sudo cp jenkins_start.sh /etc/init.d/jenkins
sudo chmod +x /etc/init.d/jenkins
sudo update-rc.d jenkins defaults

启动Jenkins服务：

启动或重新启动Jenkins服务：

对于 Systemd：
对于 SysV init：

sudo systemctl start jenkins

sudo service jenkins start

现在，Jenkins应该会在系统启动时自动启动。

备注:
Jenkins的开机自启动过程可能因操作系统而异，因此上述方法适用于大多数基于 systemd 或 SysV init 的 Linux 发行版。

启动时报错情况

错误情况1

[root@lv jenkins]# sudo systemctl start jenkins
Failed to start jenkins.service: Unit is not loaded properly: Invalid argument.
See system logs and 'systemctl status jenkins.service' for details.

该错误表明 Systemd 在尝试启动 Jenkins 服务时遇到了问题，可能是由于服务单元文件的配置问题或其他原因导致的。可以按照以下步骤来排查和解决问题：

检查 Systemd 服务单元文件：
- 确保你的 Jenkins 服务单元文件（通常在 /etc/systemd/system/jenkins.service）的语法和配置正确。确保文件路径、权限等都是正确的。
- 检查 ExecStart 行是否指向正确的 Jenkins 启动脚本。
检查 Systemd 日志：
- 运行以下命令查看详细的 Systemd 日志信息：

sudo journalctl -xe | grep jenkins

这将显示与 Jenkins 服务相关的详细日志，你可以从中获取更多信息以了解问题所在。

使用 systemctl status 查看服务状态：
- 运行以下命令以获取 Jenkins 服务的状态信息：

sudo systemctl status jenkins

这将提供关于 Jenkins 服务的当前状态、最后一次失败的详细信息等。

确保服务单元文件加载正确：
- 运行以下命令重新加载 Systemd 管理的单元文件：

sudo systemctl daemon-reload

然后再尝试启动 Jenkins 服务：

sudo systemctl start jenkins

错误情况2 (状态码为 217/USER)用户权限问题

[root@lv jenkins]# sudo systemctl status jenkins
● jenkins.service - JenkinsServer
   Loaded: loaded (/etc/systemd/system/jenkins.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since 三 2024-01-03 16:09:43 CST; 23min ago
  Process: 20795 ExecStart=/home/soft/jenkins/jenkins_start.sh (code=exited, status=217/USER)
 Main PID: 20795 (code=exited, status=217/USER)

1月 03 16:09:42 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:42 lv systemd[1]: jenkins.service failed.
1月 03 16:09:43 lv systemd[1]: jenkins.service holdoff time over, schedul...t.
1月 03 16:09:43 lv systemd[1]: Stopped JenkinsServer.
1月 03 16:09:43 lv systemd[1]: start request repeated too quickly for jen...ce
1月 03 16:09:43 lv systemd[1]: Failed to start JenkinsServer.
1月 03 16:09:43 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:43 lv systemd[1]: jenkins.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

根据 systemctl status jenkins 命令的输出，Jenkins 服务启动失败，错误状态码为 217/USER。这通常表示有关用户权限的问题。
(这里之前jenkins.service里的用户我写的是jenkins创建的用户, 发现权限不够, 就用了root,然后问题解决了)
确保以下几点：

用户权限： Jenkins 应该以具有足够权限的用户身份运行。在你的 Jenkins 服务配置文件中 (/etc/systemd/system/jenkins.service) 的 jenkins_start.sh 脚本中，确保指定的用户 (User=) 具有足够的权限访问所需的文件和目录。
脚本路径和权限： 检查 jenkins_start.sh 脚本的路径是否正确，并确保该脚本有可执行权限。
环境变量： 如果 jenkins_start.sh 中使用了环境变量（例如 $JENKINS_HOME**，**$ JENKINS_WAR 等），请确保这些变量在执行脚本时已正确设置。
日志查看： 查看 journalctl 日志以获取更详细的错误信息，可以使用以下命令：

sudo journalctl -xe | grep jenkins

查看错误信息后, 发现是下方的错误(用户 (USER) 执行 Jenkins 服务启动脚本时无法找到对应的进程)

[root@lv system]# sudo journalctl -xe | grep jenkins
1月 03 15:59:32 lv sudo[25333]:     root : TTY=pts/2 ; PWD=/home/soft/jenkins ; USER=root ; COMMAND=/bin/systemctl start jenkins
1月 03 16:03:34 lv sudo[4551]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl status jenkins
1月 03 16:04:59 lv sudo[8556]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl start jenkins
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:04:59 lv systemd[8563]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:04:59 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:04:59 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:04:59 lv systemd[1]: jenkins.service failed.
1月 03 16:04:59 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:04:59 lv systemd[8600]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:04:59 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:04:59 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:04:59 lv systemd[1]: jenkins.service failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:05:00 lv systemd[8603]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:05:00 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:05:00 lv systemd[1]: jenkins.service failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:05:00 lv systemd[8625]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:05:00 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:05:00 lv systemd[1]: jenkins.service failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:05:00 lv systemd[8627]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:05:00 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:05:00 lv systemd[1]: jenkins.service failed.
1月 03 16:05:00 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
1月 03 16:05:00 lv systemd[1]: start request repeated too quickly for jenkins.service
-- Subject: Unit jenkins.service has failed
-- Unit jenkins.service has failed.
1月 03 16:05:00 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:05:00 lv systemd[1]: jenkins.service failed.
1月 03 16:05:16 lv sudo[9387]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl status jenkins
1月 03 16:05:39 lv sudo[10461]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl status jenkins
1月 03 16:05:47 lv sudo[10863]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl status jenkins
1月 03 16:09:31 lv sudo[20156]:     root : TTY=pts/2 ; PWD=/home/soft/jenkins ; USER=root ; COMMAND=/bin/systemctl status jenkins
1月 03 16:09:41 lv sudo[20721]:     root : TTY=pts/2 ; PWD=/home/soft/jenkins ; USER=root ; COMMAND=/bin/systemctl start jenkins
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:09:41 lv systemd[20728]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:09:41 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:09:41 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:41 lv systemd[1]: jenkins.service failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:09:42 lv systemd[20755]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:09:42 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:42 lv systemd[1]: jenkins.service failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:09:42 lv systemd[20757]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:09:42 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:42 lv systemd[1]: jenkins.service failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:09:42 lv systemd[20777]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:09:42 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:42 lv systemd[1]: jenkins.service failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:09:42 lv systemd[20795]: Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process
-- Subject: Process /home/soft/jenkins/jenkins_start.sh could not be executed
-- The process /home/soft/jenkins/jenkins_start.sh could not be executed and failed.
1月 03 16:09:42 lv systemd[1]: jenkins.service: main process exited, code=exited, status=217/USER
1月 03 16:09:42 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:42 lv systemd[1]: jenkins.service failed.
1月 03 16:09:43 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
1月 03 16:09:43 lv systemd[1]: start request repeated too quickly for jenkins.service
-- Subject: Unit jenkins.service has failed
-- Unit jenkins.service has failed.
1月 03 16:09:43 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:09:43 lv systemd[1]: jenkins.service failed.
1月 03 16:32:53 lv sudo[22084]:     root : TTY=pts/2 ; PWD=/home/soft/jenkins ; USER=root ; COMMAND=/bin/systemctl status jenkins
1月 03 16:33:36 lv sshd[24096]: Invalid user jenkins from 117.34.125.66 port 56048
1月 03 16:33:36 lv sshd[24096]: input_userauth_request: invalid user jenkins [preauth]
1月 03 16:33:38 lv sshd[24096]: Failed password for invalid user jenkins from 117.34.125.66 port 56048 ssh2
1月 03 16:35:14 lv sudo[28807]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl start jenkins
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:35:14 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:35:14 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:35:15 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:35:15 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
-- Subject: Unit jenkins.service has finished start-up
-- Unit jenkins.service has finished starting up.
1月 03 16:35:15 lv systemd[1]: jenkins.service holdoff time over, scheduling restart.
-- Subject: Unit jenkins.service has finished shutting down
-- Unit jenkins.service has finished shutting down.
1月 03 16:35:15 lv systemd[1]: start request repeated too quickly for jenkins.service
-- Subject: Unit jenkins.service has failed
-- Unit jenkins.service has failed.
1月 03 16:35:15 lv systemd[1]: Unit jenkins.service entered failed state.
1月 03 16:35:15 lv systemd[1]: jenkins.service failed.
1月 03 16:35:19 lv sudo[29078]:     root : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/systemctl status jenkins

具体的错误消息为：

Failed at step USER spawning /home/soft/jenkins/jenkins_start.sh: No such process

这可能是由于脚本中的用户不存在或脚本的路径不正确引起的。请确保在 jenkins.service 文件中配置的用户存在，并且脚本的路径正确。在 jenkins.service 文件中你配置了 User=your_jenkins_user，请确保 your_jenkins_user 是存在的系统用户。
然后尝试了手动执行脚本 /home/soft/jenkins/jenkins_start.sh 看能否成功执行, 发现手动执行可以运行脚本

/home/soft/jenkins/为脚本所在目录
/home/soft/jenkins/jenkins_start.sh

看看是否有任何错误消息。确保在执行时没有任何问题。
如果脚本权限不够可以使用以下命令来添加执行权限
chmod +x /home/soft/jenkins/jenkins_start.sh

七.遇到的一些问题

1. Jenkins启动报错：AWT is not properly configured on this server.

Jenkins启动报错信息
AWT is not properly configured on this server. Perhaps you need to run your container with “-Djava.awt.headless=true”? See also: https://www.jenkins.io/redirect/troubleshooting/java.awt.headless

解决方案:
jenkins所在服务器安装一些基本的字体和与 X Window System 相关的工具，使系统能够更好地处理图形界面的显示和渲染.

yum -y install dejavu-sans-fonts fontconfig xorg-x11-server-Xvfb

2. 本地和服务器上的 Java 版本需一致

服务端用的是jdk11版本, 因为启动jenkins需要11以上
本地用的是jdk8 , 发版时拉取代码, 发现没有jdk高版本向下兼容的情况,会报错

javacTask: 源发行版 1.8 需要目标发行版 1.8
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] An unknown compilation problem occurred
[INFO] 1 error
[INFO] -------------------------------------------------------------

Maven 编译插件默认会使用本地 JDK 版本进行编译。
如果本地项目的 Java 版本是 8，而服务器上的 JDK 版本是 11，可能会出现不兼容的情况。
解决方法之一是确保本地和服务器上的 Java 版本一致
所以我把本地maven中的setting.xml 和 jdk版本都切换成11了

maven中的setting.xml中指定


<profiles>
	<profile>
    <id>default</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
    </properties>
    </profile>
</profiles>

项目总pom中jdk指定

maven-compiler-plugin的3.11.0 也有版本要求, 3.8版本的不支持11.
可以去https://mvnrepository.com/ maven获取这里自行看一下,我这里指定的是3.11.0

 <build>
        <plugins>
            <!-- java编译插件 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.11.0</version>
                <configuration>
                    <source>11</source>
                    <target>11</target>
                    <encoding>UTF-8</encoding>
                    <compilerArgument>-parameters</compilerArgument>
                </configuration>
            </plugin>
		</plugins>
 </build>

都切换好后, 可以在Idea终端中执行下方命令查看下是否版本切换成功, 和mvn能否构建成功

java -version   --查看jdk版本
mvn -version	--查看maven配置信息
mvn clean install -e   --运行 Maven 构建以查看详细信息(看是否报错)

3. pom打包jar包到服务器命名方式问题

使用对应模块打包方式为jar

<modelVersion>4.0.0</modelVersion>
<packaging>jar</packaging> --模块打包方式

打包jar包到服务器命名方式设置

在对应模块的pom文件中,我下方定义了该模块name为gateway,
所以在 build中的finalName中引用定义的名称,

<artifactId>test_geteway</artifactId>
<version>1.0.0</version>
<name>gateway</name>   -- 定义打包名称
<description>gateway网关</description>

 <build>
        <finalName>${project.name}</finalName>  --根据build中的fileName进行jar包的命名
</build>

使用repackage确保生成的jar文件可以通过"java-jar" 命令直接运行

Spring Boot 插件的 repackage 目标 用于将应用程序打包为可执行的 JAR 文件。
它将重新打包项目的 JAR 文件，以确保包含所有依赖项，并将可执行 JAR 的主类信息正确配置到清单文件中。
这有助于确保生成的 JAR 文件可以通过 java -jar 命令直接运行,不然会报清单相关问题

<build>
        <finalName>${project.name}</finalName>  --引用打包名称
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal> 
								--repackage将可执行 JAR 的主类信息正确配置到清单文件中
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

4. 服务器接收不到jenkins发送来的jar包

已经构建成功，但是自己目录下没有，原因

假如你项目构建配置的是/usr/local/workspace
那么你的jar包被传输到 /usr/local/jenkins/usr/local/workspace里面去了

5. jenkins工作空间问题

之前项目构建后操作里的SSH server -> Transfer Set 中的 Source files 我写的是A服务器从git拉取后存放的路径, 最后发现不是, 需要填写的是jenkins工作空间的路径才可以正确将jar存放到B服务器Remote directory 指定的路径中保存

构建后操作工作空间jar包路径

test代表工作空间WORKSPACE , 后面的是路径
所以Source files中的 **/target/**.jar 是我们要传到服务器上的jar包路径

Execute shell 脚本工作空间路径

对应的${WORKSPACE}代表了上面图中的test,后面的/admin/target/admin.jar为路径

部分内容引自https://blog.csdn.net/kawayiyy123/article/details/127884383

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

云原生

所有评论(0)

查看更多评论

m0_58943936

@m0_58943936

已为社区贡献1条内容

centos7中jenkins的安装与配置(超详细)

m0_58943936

一：jenkins安装

1.官网下载Jenkins war包

2.使用命令启动(端口号自行设置开放)

3.浏览器打开http://你的服务器ip:16060/

4. 查看初始化密码(复制后填写到页面的管理员密码中)

5.启动如下

二：插件

插件安装方法

三：配置

①：配置国内的清华镜像源

②：配置maven

③：配置jdk

④：配置git

⑤：配置凭据参数

⑥：使用API token 连接GitLab的配置

1. GitLab 端生成API Token

2.Jenkins 端配置GitLab API Token

⑦：配置Publish over SSH

1.查看公钥/私钥

⑧：配置SSH Server

四：项目构建

1. 后端

①：General

②：源码管理

③：构建触发器 不做任何配置 略过

④：构建环境 不做任何配置 略过

⑤：构建

配置Maven相关内容

ssh命令内容 (具体内容可以看本章内容五模块 )

⑥：构建后操作

五：Execute shell 中的ssh命令

1.查看和修改本地主机名与 IP 地址的映射关系

问题1:(没有设置映射,导致找不到test-sever)

1.查看映射关系

2. 修改本地主机名与 IP 地址的映射关系

3. 测试是否成功解析

2.查看公钥/私钥

3.两台机器实现互相通信

问题2(没有设置互通,导致还需要输入密码, 提示权限被拒绝 )

1 服务器 A 和服务器 B 之间建立通信

4.ssh执行命令

1.jenkins部署后的操作将jar传入目标服务器并且运行jar包 执行命令

2. sh脚本运行jar包及生成日志

3.配置好后进入项目,进行构建

六.使用启动脚本实现开机自启动jenkins

创建启动脚本并使用脚本启动服务

创建Jenkins启动脚本：

添加执行权限：

配置Jenkins开机自启动：

启动Jenkins服务：

启动时报错情况

错误情况1

错误情况2 (状态码为 217/USER)用户权限问题

七.遇到的一些问题

1. Jenkins启动报错：AWT is not properly configured on this server.

2. 本地和服务器上的 Java 版本需一致

3. pom打包jar包到服务器命名方式问题

使用对应模块打包方式为jar

打包jar包到服务器命名方式设置

使用repackage确保生成的jar文件可以通过"java-jar" 命令直接运行

4. 服务器接收不到jenkins发送来的jar包

5. jenkins工作空间问题

构建后操作工作空间jar包路径

Execute shell 脚本工作空间路径

所有评论(0)

m0_58943936

③：构建触发器不做任何配置略过

④：构建环境不做任何配置略过

1.jenkins部署后的操作将jar传入目标服务器并且运行jar包执行命令