【jenkins】jenkins+gitlab实现一键构建部署

程序员王多余 2024-09-11 17:37:01 阅读 70

Jenkins,原名 Hudson,2011 年改为现在的名字。它是一个开源的实现持续集成的软件工具。

官方网站

https://www.jenkins.io/

一、GitLab安装使用(服务器1)

官方网站:https://about.gitlab.com/

安装所需最小配置

内存至少4G

https://docs.gitlab.cn/jh/install/requirements.html

1、在ssh下安装

官方安装文档:https://gitlab.cn/install/?version=ce

1 安装依赖

<code>sudo yum install -y curl policycoreutils-python openssh-server perl

sudo systemctl enable sshd

sudo systemctl start sshd

2 配置镜像

curl -fsSL https://packages.gitlab.cn/repository/raw/scripts/setup.sh | /bin/bash

3 开始安装

sudo EXTERNAL_URL=“http://192.168.81.128” yum install -y gitlab-jh

其中的ip就是需要安装gitlab服务器的ip

除非您在安装过程中指定了自定义密码,否则将随机生成一个密码并存储在 /etc/gitlab/initial_root_password 文件中(出于安全原因,24 小时后,此文件会被第一次 gitlab-ctl reconfigure 自动删除,因此若使用随机密码登录,建议安装成功初始登录成功之后,立即修改初始密码)。使用此密码和用户名 root 登录。

4 注意:启动后如果在宿主机访问网址发现打不开,可能是虚拟机内的防火墙没有关闭;

查看防火墙状态:

systemctl status firewalld

image.png

关闭防火墙:

<code>service firewalld stop

关闭之后重新启动虚拟机还是会开启防火墙,输入以下命令可以开机也不开启防火墙:

systemctl disable firewalld

image.png

重新访问 http://192.168.81.128/

image.png

刚开始访问提示502,稍等一会刷新一下就进入登录页面

image.png

登录用户名是 root,密码存储在服务器 /etc/gitlab/initial_root_password 文件里

image.png

5 gitlab常用命令

<code>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                   # 查看日志;

2、在docker下安装

https://docs.gitlab.cn/jh/install/docker.html

安装所需最小配置

内存至少4G系统内核至少在3.10以上 uname -r 命令可查看系统内核版本

1 安装docker

更新yum源

yum update

安装依赖

yum install -y yum-utils device-mapper-persistent-data lvm2

添加镜像

//国外镜像

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

//阿里镜像

https://mirrors.aliyun.com/docker-ce/linux/centos/gpg

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

查看源中可使用版本

yum list docker-ce --showduplicates | sort -r

安装指定版本

yum install docker

配置开机启动项

systemctl start docker

systemctl enable docker

docker version

2 使用容器安装gitlab

1.添加容器

docker run --detach \

--hostname 192.168.44.103 \

--publish 443:443 --publish 80:80 \

--name gitlab \

--restart always \

--volume $GITLAB_HOME/config:/etc/gitlab:Z \

--volume $GITLAB_HOME/logs:/var/log/gitlab:Z \

--volume $GITLAB_HOME/data:/var/opt/gitlab:Z \

--shm-size 256m \

registry.gitlab.cn/omnibus/gitlab-jh:latest

2.启动容器

docker start gitlab

3.查看已存在的容器

docker ps -a

4.进入容器

docker exec -it gitlab /bin/bash

3 访问

http://192.168.44.101

当首次运行出现502错误的时候排查两个原因

虚拟机内存至少需要4g稍微再等等刷新一下可能就好了

4 管理员账号登录

用户名:root

密码存在下面文件中,登录后需要改密码不然24小时之后会失效

cat /etc/gitlab/initial_root_password

二、Jenkins安装(服务器2)

官方文档介绍非常详细

https://www.jenkins.io

war包地址:jenkins.war https://www.aliyundrive.com/s/sBHD8FcZSQ8

安装需求

机器要求:

256 MB 内存,建议大于 512 MB

10 GB 的硬盘空间(用于 Jenkins 和 Docker 镜像)

需要安装以下软件:

Java 8 ( JRE 或者 JDK 都可以)

Docker (导航到网站顶部的Get Docker链接以访问适合您平台的Docker下载)

1、安装JDK

java -version确认当前服务器是否已经有jdk

如果有,卸载掉

yum -y remove java-1.8.0-openjdk*

1 检索可用包

yum search java|grep jdk

2 安装

yum install java-11-openjdk

2、启动jenkins

java -jar jenkins.war

首次启动war包会在/root/.jenkins生成配置文件

待完全启动成功后 访问服务器8080端口完成配置

初始化后的密码:

Jenkins initial setup is required. An admin user has been created and a password generated.

Please use the following password to proceed to installation:

4e67bbe261da476abdc63c5b51311646

This may also be found at: /root/.jenkins/secrets/initialAdminPassword

密码文件使用后会自动删除

访问地址:http://192.168.81.129:8080/,输入用户名密码。选择推荐插件,安装

image.png

安装完成后进入首页

image.png

3、将jenkins设置为开机自启

(1)创建 Jenkins systemd 配置文件:

<code>sudo vi /etc/systemd/system/jenkins.service

[Unit]

Description=Jenkins Service

After=network.target

[Service]

User=root

ExecStart=/usr/bin/java -jar /root/jenkins.war

SuccessExitStatus=143

[Install]

WantedBy=multi-user.target

(2)执行以下命令,重新加载 Systemd 配置:

sudo systemctl daemon-reload

(3)启动 Jenkins 服务:

sudo systemctl start jenkins

(4)验证 Jenkins 是否在后台运行:

sudo systemctl status jenkins

(5)执行以下命令,将 Jenkins 设置为开机自启:

sudo systemctl enable jenkins

4、Maven安装

官网

https://maven.apache.org/

下载后复制到Jenkins所在服务器

解压缩

tar zxvf apache-maven-3.9.0-bin.tar.gz

转移目录

mv apache-maven-3.9.0 /usr/local/maven

测试是否正常

/usr/local/maven/bin/mvn

image.png

如图表示可用

三、jenkins+maven+git自动构建jar包

1、安装maven插件

image.png

image.png

image.png

2、配置maven

image.png

修改maven配置文件 /usr/local/maven/conf/settings.xml

<code><?xml version="1.0" encoding="UTF-8"?>code>

<!--

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"code>

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"code>

xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">code>

<!-- 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>

<!--This sends everything else to /public -->

<id>nexus</id>

<mirrorOf>*</mirrorOf>

<url>http://maven.aliyun.com/nexus/content/groups/public/</url>

</mirror>

<mirror>

<!--This is used to direct the public snapshots repo in the

profile below over to a different nexus group -->

<id>nexus-public-snapshots</id>

<mirrorOf>public-snapshots</mirrorOf>

<url>http://maven.aliyun.com/nexus/content/repositories/snapshots/</url>

</mirror>

<mirror>

<!--This is used to direct the public snapshots repo in the

profile below over to a different nexus group -->

<id>nexus-public-snapshots1</id>

<mirrorOf>public-snapshots1</mirrorOf>

<url>https://artifacts.alfresco.com/nexus/content/repositories/public/</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>

3、安装git

yum install -y git

检查版本

git --version

image.png

4、配置git

获取git路径

<code>which git

image.png

image.png

5、配置jdk

<code>ls -lrt /usr/bin/java

ls -lrt /etc/alternatives/java

ll /usr/lib/jvm/

image.png

jre-11-openjdk 就是环境变量

编辑环境变量,在文件 /etc/profile 后面追加如下内容

<code>export JAVA_HOME=/usr/lib/jvm/jre-11-openjdk

export JRE_HOME=$JAVA_HOME/jre

PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin

export JAVA_HOME JRE_HOME CLASS_PATH PATH

刷新环境变量 source /etc/profile 立即生效

image.png

6、构建jar包

新建任务

image.png

image.png

image.png

image.png

image.png

查看jar包

<code>ll /root/.jenkins/workspace/maven-demo/target/

image.png

四、Jenkins + Git + Maven 自动化部署配置(目标服务器3)

以下操作是以上面Maven项目为基础进行配置

1、安装插件

image.png

2、添加一台目标服务器

image.png

image-20220726223937722.png

3、配置插件

image.png

image.png

将jenkins服务器目录下:/root/.jenkins/workspace/demo 任务内所有jar文件通过SSH发送到目标服务器的/root/xxoo下。

exec command 输入框内输入的内容,是要在目标服务器上运行的命令,此处填写 java -jar /root/xxoo/target/*.jar & ,表示在后台运行/root/xxoo/target目录下的jar文件

4、开始构建

image.png

目标服务器:/root/xxoo/目录下:

image.png

输入ps -ef | grep java 可以看见服务已经跑起来了。

image.png

访问http://192.168.81.131:8080/test/helloWorld

image.png

5、超时机制

有时候由于命令的问题,会导致jenkins构建超时,是因为所执行的命令在shell里执行时窗口会卡主,Jenkins会认为认为一直没完成(实际上服务已经起来了)

java -jar /root/xxoo/target/springboot-demo-0.0.1-SNAPSHOT.jar &

nohup java -jar /root/xxoo/target/*.jar &

这两个命令都可以导致命令行窗口卡住:

image.png

image.png

image.png

此时就会导致jenkins构建时间过长,超过配置的2分钟限制。

解决办法:优化命令

1 数据流重定向

数据流重定向就是将某个命令执行后应该要出现在屏幕上的数据传输到其他地方

标准输入(stdin):代码为0,使用<或<<;标准输出(stdout):代码为1,使用>或>>;标准错误输出(stderr):代码为2,使用2>或2>>

覆盖写>> 追加写

<code>nohup java -jar /root/xxoo/target/*.jar >mylog.log 2>&1 &

image.png

这条命令不会导致窗口卡住。修改jenkins配置:

image.png

image.png

构建时间大大缩短。

6、构建前置清理脚本

可以配置jenkins在构建之前执行的命令,也可以将命令写成shell脚本,执行脚本文件。

image.png

如图配置会执行 /root/x.sh脚本,并传一个参数demo(需要给x.sh添加执行权限:chmod u+x x.sh)

<code>#!/bin/bash

#删除历史数据

rm -rf xxoo

appname=$1

#获取传入的参数

echo "arg:$1"

#获取正在运行的jar包pid

pid=`ps -ef | grep $1 | grep 'java -jar' | awk '{printf $2}'`

echo $pid

#如果pid为空,提示一下,否则,执行kill命令

if [ -z $pid ];

#使用-z 做空值判断

then

echo "$appname not started"

else

kill -9 $pid

echo "$appname stoping...."

check=`ps -ef | grep -w $pid | grep java`

if [ -z $check ];

then

echo "$appname pid:$pid is stop"

else

echo "$appname stop failed"

fi

fi

配置好后再构建之前,会执行指定的脚本,删除原有的项目文件并停掉服务。

7、几种构建方式

1 触发远程构建

进行如图所示配置,配置好后,访问指定URL即可触发远程构建

http://192.168.81.129:8080/job/demo/build?token=111111

image.png

可以看到访问URL之后,出发了构建

image.png

但是这个URL只能在当前浏览器访问才能触发构建,用其他浏览器或者postman请求会提醒登录,此时需要安装插件 Build Authorization Token Root Plugin

image.png

安装后访问如下URL:http://192.168.81.129:8080/buildByToken/build?job=demo&token=111111

image.png

查看构建状态:

image.png

2 gitlab钩子自动构建

首先勾选如下配置:

image.png

然后配置webhosts,注意不要勾选SSL,确定添加

image.png

出现如下配置表示配置成功

image.png

接下来就可以在gitlab上创建合并请求,Jenkins会自动去构建项目

需要注意的是:创建合并请求和点击合并,都会触发构建

image.png

image.png

访问接口可以看见更新后的结果:

image.png

3 定时构建
Jenkins cron表达式

标准cron

https://crontab.guru

Jenkins cron不是标准的cron表达式

<code>第一个 * 表示每个小时的第几分钟,取值0~59

H * * * *

H:每小时执行一次

第二颗 * 表示小时,取值0~23

* 15 * * * 表示每天下午3点

* 1 * * * 表示每天凌晨1点

第三颗 * 表示一个月的第几天,取值1~31

* 1 5 * * 表示每月5日凌晨1点

第四颗 * 表示第几月,取值1~12

* 15 5 1 * 表示每年几月执行

第五颗 * 表示一周中的第几天,取值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

4 源码变更构建

使用Poll SCM 方式与Build periodically一样

会主动定期检查代码托管服务器上的代码与Jenkins上的代码相比是否有变化,一旦发生变化执行job构建

8、测试报告邮件通知

1 系统配置

使用QQ邮箱生成授权码:

image.png

配置jenkins邮件发送

image.png

image.png

image.png

image.png

image.png

点击测试,邮箱收到内容:

b62b7de6bb6d892a043193e53cf726e.jpg

2 项目配置

image.png

image.png

配置触发器用户组

image.png

点击构建,观察日志:

image.png

邮箱收到邮件:

image.png

9、自动化部署到docker容器中(服务器4)

1 配置yum源

<code>sudo yum install -y yum-utils

sudo yum-config-manager \

--add-repo \

http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

2 安装docker

sudo yum install -y docker-ce docker-ce-cli containerd.io

3 下载jdk镜像

Docker

image.png

image.png

<code>FROM java:7

COPY . /usr/src/myapp

WORKDIR /usr/src/myapp

RUN javac Main.java

CMD ["java", "Main"]

4 将jar包打包到镜像内

传一个jar包到服务器上

image.png

将文件移动到 /root/jarfile 文件夹下

image.png

编写dockerfile

image.png

<code>FROM openjdk:11

EXPOSE 8080

WORKDIR /root

# 此处的.jar文件路径是相对于 dockerfile的路径

ADD *.jar /root/app.jar

ENTRYPOINT ["java","-jar","/root/app.jar"]

启动docker服务

# 启动docker服务

service docker start

# 构建docker镜像,demo 是别名,.表示dockerfile在当前目录下

docker build -t demo .

image.png

查看镜像

<code>docker images

image.png

启动镜像

<code># 启动镜像

docker run -d --name demo -p 8080:8080 demo

# 查看启动中的镜像

docker ps

image.png

访问服务:192.168.81.132:8080/test/helloWorld

image.png

5 通过外挂jar包自动化部署到docker

<code># 安装openjdk镜像

docker pull openjdk:11

# docker运行外挂目录

docker run -d -p 8080:8080 --name demo-out -v /root/jarfile/springboot-demo-0.0.1-SNAPSHOT.jar:/app.jar openjdk:11 java -jar app.jar

image.png

image.png

配置docker相关命令

<code># 删除root目录下所有内容

rm -rf *

# 停止demo-out容器

docker stop demo-out

# 删除demo-out镜像

docker rm demo-out

image.png

<code># 重新从外挂目录运行docker容器

docker run -d -p 8080:8080 --name demo-out -v /root/jarfile/target/springboot-demo-0.0.1-SNAPSHOT.jar:/app.jar openjdk:11 java -jar app.jar

image.png

修改代码,合并分支后自动构建

image.png

五、Jenkins集群/并发构建

集群化构建可以有效提升构建效率,尤其是团队项目比较多或是子项目比较多的时候,可以并发在多台机器上执行构建。

image.png

点击新建节点

image.png

image.png

image.png

六、流水线 pipeline

1、流水线测试

流水线既能作为任务的本身,也能作为Jenkinsfile

使用流水线可以让我们的任务从ui手动操作,转换为代码化,像docker的dockerfile一样,从shell命令到配置文件,更适合大型项目,可以让团队其他开发者同时参与进来,同时也可以编辑开发Jenkinswebui不能完成的更复杂的构建逻辑,作为开发者可读性也更好。

<code># jenkins脚本5个必备的组成部分

pipeline:整条流水线

agent:指定执行器

stages:所有阶段

stage:某一阶段,可有多个

steps:阶段内的每一步,可执行命令

post:

流水线完成后可执行的任务

● always 无论流水线或者阶段的完成状态。

● changed 只有当流水线或者阶段完成状态与之前不同时。

● failure 只有当流水线或者阶段状态为"failure"运行。

● success 只有当流水线或者阶段状态为"success"运行。

● unstable 只有当流水线或者阶段状态为"unstable"运行。例如:测试失败。

● aborted 只有当流水线或者阶段状态为"aborted "运行。例如:手动取消。

image.png

输入脚本

<code>pipeline {

agent any

stages {

stage('拉取代码') {

steps {

echo '拉取代码完成'

}

}

stage('执行构建') {

steps {

echo '执行构建完成'

}

}

}

post {

always {

echo "完成"

}

failure {

echo "失败"

}

}

}

image.png

点击构建,查看控制台输出如下内容

image.png

状态中可以查看各个阶段的日志

image.png

2、使用blue ocean可视化插件

搜索插件并安装

image.png

image.png

安装完成后会有如下菜单

image.png

点击会进入如下界面

image.png

构建后,点击构建列表可以查看构建详情

image.png

3、使用流水线执行自动化构建

1 配置git

image.png

image.png

点击生成流水线脚本

<code>git branch: 'main', credentialsId: 'gitlab', url: 'http://192.168.81.128/root/demo.git'

将生成的脚本粘贴到jenkins脚本的拉取代码步骤中

image.png

2 配置maven

查看当前maven配置

image.png

修改jenkins脚本,tools配置中,引号内的内容需要与maven配置中的name一致

sh "mvn --version"测试maven是否生效

image.png

点击构建,查看日志

image.png

image.png

说明目前配置的没问题,修改脚本,开始构建项目 mvn clean package

image.png

image.png

image.png

出现如上日志表示构建成功。

3 将打包生成的jar包发送到测试服务器上并启动

生成清理目标服务器的脚本

image.png

生成将jar包发送到测试服务器并启动的流水线脚本

image.png

<code>pipeline {

agent any

tools {

maven "maven3"

}

stages {

stage('拉取代码') {

steps {

git branch: 'main', credentialsId: 'gitlab', url: 'http://192.168.81.128/root/demo.git'

echo '拉取代码完成'

}

}

stage('构建') {

steps {

sh "mvn clean package"

echo '执行构建完成'

}

}

stage('准备容器'){

steps{

sshPublisher(publishers: [sshPublisherDesc(configName: 'test-server', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: '''rm -rf *

docker stop demo-out

docker rm demo-out''', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '/root')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])

echo '清理完成'

}

}

stage('部署'){

steps{

sshPublisher(publishers: [sshPublisherDesc(configName: 'test-server', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: 'docker run -d -p 8080:8080 --name demo-out -v /root/jarfile/target/springboot-demo-0.0.1-SNAPSHOT.jar:/app.jar openjdk:11 java -jar app.jar', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: '/jarfile', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '**/*.jar')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])

echo '发送并启动完成'

}

}

}

post {

always {

echo "完成"

}

failure {

echo "失败"

}

}

}

构建并查看结果

image.png

4、多分支流水线构建

1 创建多分支流水线任务

image.png

image.png

2 给两个分支上传Jenkinsfile

image.png

image.png

Jenkinsfile内容如下:

image.png

image.png

查看扫描多分支流水线日志

image.png

image.png

3 分别构建两个分支

image.png

image.png

4 声明式流水线

好处

更像是在Jenkins web ui中的操作可读性比较高可以使用blue ocean自动生成支持语法检查

坏处

代码逻辑能力比脚本式弱,不能完成特别复杂的任务

5 脚本式流水线

好处

更少的代码和弱规范要求更灵活的自定义代码操作不受约束,可以构建特别复杂的工作流和流水线

坏处

读写对编程要求比较高比声明式流水线代码更复杂



声明

本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。