Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具

持续集成(CI)是在源代码变更后自动检测、拉取、构建和(在大多数情况下)进行单元测试的过程

可以简单将jenkins理解为一个代码部署工具。
在没有持续部署工具之前,开发部署代码到服务器上是需要一定的流程的,比如合并代码,然后相关人员将代码更新到服务器(旧代码覆盖),运行一些指令让新代码生效,然后观察运行情况。
流程听起来好像还挺简单的,但是谁能保证部署人员的每一步都没有差错呢?需要部署的服务多的话,也很费时间。

一般情况下,人工部署到服务器的步骤都是固定的,那是不是表示可以动一些“歪点子”(脚本程序),让脚本替代部署人员去做部署的工作呢?懒人表示肯定能行。

Jenkins就是按照人工部署的步骤,代替人工操作,将代码部署到指定服务器并运行的工具(老板表示这个工具非常好,又可以炒人了)。

我们本章以tomcat web为例进行jenkins的入门操作。考虑到本地配置jenkins和tomcat服务会让入门人员产生一定的混淆,所以本章以一台电脑和远程可访问的服务器进行配置。我的预想是在本地配置jenkins服务,在远程服务器中部署tomcat服务。其实都可以在本地电脑上配置,思路上是一样的,只是环境配置不太一样,这个可以去网上搜搜安装教程。

在实践之前,我们先思考几个问题:

1、jenkins是怎么部署tomcat运行环境的?
2、jenkins怎么识别我想要它部署的代码?或者代码是怎么上传到服务器上的?

首先,Jenkins只是根据人工部署代码的步骤去部署代码到服务器,并不能去配置服务器的运行环境,运行环境还是要自己配置好。所以还是自己去服务器上配置tomcat运行环境。但是jenkins可以安装一些库之类的。
想要让jenkins将指定代码部署到服务器上,我们就得告诉jenkins从哪里下载代码,并告诉jenkins部署到哪台服务器。
jenkins的插件会去远程仓库下载代码,然后通过配置传送到指定服务器上,所以我们可以将html文件(即代码)上传到远程仓库,让jenkins去更新到服务器。
注意:为了方便理解,这里就用很简单的例子进行讲解——部署tomcat运行的html文件

根据以上思路,我们目前需要操作:
1、手动在服务器配置tomcat服务并运行
2、本地配置jenkins服务,并配置项目
3、让jenkins部署代码并让代码运行(一般叫构建)

远程服务器配置

运行tomcat服务需要有jdk环境,所以远程服务器需要先安装jdk

Linux安装jdk

下载jdk:https://www.oracle.com/java/technologies/downloads/
可以通过arch命令查看下载哪个tar.gz包
在这里插入图片描述
在这里插入图片描述
复制对应安装包的链接,通过curl -o 下载后文件名称.tar.gz 安装包链接的方式下载安装包
远程服务器命令:curl -o jdk.tar.gz https://download.oracle.com/java/20/latest/jdk-20_linux-x64_bin.tar.gz
在这里插入图片描述
如果服务器可以使用wget命令的话,可以通过wget命令下载:wget https://download.oracle.com/java/20/latest/jdk-20_linux-x64_bin.tar.gz
下载成功后,解压
在这里插入图片描述

解压后多了个目录(我这里是jdk-20),进入该目录,可以看出有bin目录和lib目录
在这里插入图片描述
要将bin目录和lib目录配置到系统环境配置中,类似于windows设置系统环境变量的作用,让系统可以根据路径查到对应的命令文件
vi /etc/profile命令打开配置文件,输入i进入编辑模式,添加如下内容后,按Esc键退出编辑,然后输入:wq保存退出:

export JAVA_HOME=/root/jdk_ins/jdk-20
CLASSPATH=$JAVA_HOME/lib/
PATH=$PATH:$JAVA_HOME/bin
export PATH JAVA_HOME CLASSPATH

注意:JAVA_HOME就是我们解压的jdk目录

编辑成功后,输入如下命令让修改后的配置文件生效,命令:source /etc/profile
然后输入java -version命令查看jdk是否生效,如下正常输出了java version的版本信息就表示安装成功了
在这里插入图片描述

配置tomcat服务

服务器的jdk配置好之后,就可以配置tomcat服务了。首先先下载tomcat包
tomcat官网:https://tomcat.apache.org/
在这里插入图片描述
新建一个tomcat_web目录,用来存放下载的tomcat安装包,然后解压
在这里插入图片描述
在这里插入图片描述
一开始访问服务器的8080端口,提示失败,怀疑是服务器的端口没有开放,所以又去开放了8080端口(每个服务器的开放端口命令可能不太一样,腾讯云服务器、阿里云服务器都有控制台可以设置,我的服务器没有控制台,但是可以通过firewall-cmd命令开放端口,具体如下:
在这里插入图片描述
firewall-cmd --query-port=8080/tcp是判断8080端口是否开放,为no表示没有开放,为yes表示开放了;
firewall-cmd --add-port=8080/tcp --permanent:添加开放的端口8080
firewall-cmd --reload:重载添加的端口
将8080端口开放后,访问服务器8080端口,访问正常
在这里插入图片描述
在tomcat解压目录下,进入/webapps/ROOT目录,编写test.html内容
在这里插入图片描述
在这里插入图片描述
服务器的tomcat服务配置好了,接下来来配置本地的jenkins服务

Jenkins配置

window安装jdk

Jenkins是使用Java编写的,所以需要安装并配置JDK环境
Jenkins对JDK版本是有要求的(具体的可以看Jenkins官网:Java requirements
在这里插入图片描述

目前Jenkins最新版本是2.375,所以JDK11~JDK17是可以满足要求的,选择JDK17的版本,JDK下载地址:https://www.oracle.com/java/technologies/downloads/
在这里插入图片描述
选择免安装版本,下载完成后,解压到指定目录,然后进入解压后的目录中,直到bin目录下,bin目录存放了一堆java的可执行文件,将bin目录配置到系统变量Path中
在这里插入图片描述
打开cmd窗口,输入java -version,命令正常运行则表示JDK环境配置成功
在这里插入图片描述

Jenkins安装

(https://www.oracle.com/java/technologies/downloads/)
Jenkins下载地址:Jenkins
在这里插入图片描述
下载jenkins.war,管理员身份打开cmd,使用java -jar jenkins.war来启动jenkins服务(默认占用的是8080端口,如果想占用其他端口,启动命令:java -jar jenkins.war --httpPort=端口号
在这里插入图片描述
浏览器打开http://localhost:8080/页面,首次打开jenkins服务页面需要先解锁Jenkins(即管理员密码),解锁密码页面有说明
在这里插入图片描述
不安装推荐的插件,插件后面有需要再自己安装
在这里插入图片描述
在这里插入图片描述
可以创建一个管理员用户,后续就使用该管理员登录
在这里插入图片描述
后面直接按照指示即可,最后进入jenkins首页
在这里插入图片描述

构建项目

jenkins是以项目的维度去管理的,我们先创建一个项目(item)
在这里插入图片描述

然后进入了项目的Configure(配置)页面,在这里配置相关内容,基本有如下内容:

  • General:常规配置,简要说明项目内容,以及构建(运行)项目的一些管理
  • Source Code Management:源码管理,即从哪里下载源码,源码必须存放到jenkins可以下载的地方,本地电脑经常变换,也没有插件支持,所以放在可访问的远程服务器比较方便,比如github、svn、码云等平台
  • Build Triggers:构建触发器,即什么情况下会触发构建(重新运行)
  • Build Steps:构建步骤,一般情况下,提交修改后的代码后,要使代码生效,我们都需要在更新代码的基础上去执行一些命令,让新代码生效,Build Steps可以设置这些命令

emmmm,这些概念可以先不理解,后面有它们出场的舞台。

我们想让jenkins为我们部署代码并运行,就得让Jenkins知道去哪里下载代码,还得告诉Jenkins是部署到哪个服务器

代码维护

我们写代码一般是在本地电脑上写的,然后代码是在服务器上运行的。可能有人就想了:我代码在本地,jenkins也在本地,是不是可以让jenkins识别到本地的路径,将本地的代码直接更新到服务器上去?
也不是不行(我不会)如果代码是自己一个人维护的话可以这样,但是一般项目的代码不是一个人写的,合并需要时间和团队成员的配合,项目代码也是在github等可访问的远程仓库托管,所以我们还是将代码维护到远程仓库,让jenkins去远程仓库下载,这样就算你换了新电脑,也不用去旧电脑copy代码过来,只需要配置Jenkins服务就可以了;多人的项目,大家按照指定规则将代码合并到远程仓库,就不用在部署前通知成员去合并了。

这里选择Gitee为远程仓库来托管html代码,上传到Gitee需要git工具,我们需要安装支持git命令的插件
在这里插入图片描述

jenkins服务的git插件依赖于本地的git工具,即本地需要安装git(网上有安装教程),打开命令行(不要在git安装目录下打开命令行)并输入git -v,有git version版本号出现,表示git安装成功
在这里插入图片描述

如果安装插件比较慢的话,可以将插件下载地址替换成国内镜像地址
替换方法参考这篇博客:解决 jenkins 插件下载失败问题 - 配置 jenkins 插件中心为国内镜像地址
在这里插入图片描述
在这里插入图片描述
安装成功后,重新进入项目的Configure配置页面
在这里插入图片描述
勾选git,配置远程仓库信息和登录信息
在这里插入图片描述

Jenkins的git配置好后,点击"Build Now"进行构建,Jenkins会在本地电脑构建,因为我们只配置了远程仓库的内容,所以这次构建只是下载代码(并没有上传到服务器,上传到服务器还需要进一步配置)
在这里插入图片描述
在这里插入图片描述

配置服务器信息

Jenkins下载代码运行成功后,我们还得告诉Jenkins要将代码部署到哪台服务器,即让Jenkins将下载的代码上传到到远程服务器,这一步也需要用到插件:Publish over SSH
在这里插入图片描述
安装好Publish over SSH插件后,在【Manage Jenkins】【Configure System】的Publish over SSH模块下配置远程服务器连接信息
在这里插入图片描述
服务器连接信息配置成功后,就可以在项目中进行使用了
在这里插入图片描述
在这里插入图片描述

配置到了这里,我们梳理一下我们可能达到的情况:将https://gitee.com/wenxiaoba/jenkins_demo.git的代码上传到43.252.231.68服务器的/root/jenkins_test目录下。
远程仓库的代码如下:
在这里插入图片描述
构建
在这里插入图片描述
从Console Output来看是构建成功了,我们去服务器上看看:
在这里插入图片描述
从服务器上看也是上传成功了,也就是说我们可以让Jenkins将代码部署到服务器的指定位置。
我们前面步骤中,安装了tomcat服务,tomcat服务的工作目录是其解压目录下的/webapps/ROOT,我们重新配置下项目中的Send build artifacts over SSH,更新其远程目标目录为tomcat的工作目录
在这里插入图片描述

在服务器对应目录下查看,对应目标目录下已成功上传
在这里插入图片描述
互联网访问wen.html文件:
在这里插入图片描述
可以正常访问。
到这里,基本上后面修改了本地代码,只需要更新到远程仓库,然后在Jenkins平台上构建,就可以让Jenkins将代码部署到服务器,不用自己手动去部署到服务器了。
为了方便理解,例子是用的最简单的例子,好像没省多少人力,但是如果是大型的网站呢?

Jenkins基本内容

入门实践基本上对Jenkins有一个初步的了解了,接下来对Jenkins的一些概念和配置进行详细说明

Jenkins的3个概念

Jenkins有3个重要的概念:Job(工程)、plugin(插件)、workspace(工作空间)

  • Job(任务/工程)
    • Job就是我们本章操作的“项目”,新建的“Item”,我们一般以项目的维度去管理,从Jenkins角度理解,就是它的工作或任务了
  • plugin(插件)
    • Jenkins提供了一个平台,通过各种插件来完成一个Job,类似于我们电脑的window系统,window系统提供了一个平台,然后我们可以通过各种软件(插件)来工作或娱乐。
    • 想让Jenkins干活时,先找找有没有对应的插件可用。
  • workspace(工作空间)
    • Jenkins是通过文件形式来存储和管理数据的,我们在通过项目的Console Output可以看到当前项目的工作目录
    • 每个项目都有一个独立的工作空间,用来存放Job涉及到的数据/文件,以及任务执行完成后生成的数据/文件

Manage Jenkins

Manage Jenkins下主要有一些管理配置,比如插件管理、系统配置、用户管理等

  • Global Tool Configuration:简称全局工具配置管理,如果安装的插件有多个版本,或插件依赖的运行工具有多个版本,就可以在这里进行设置,全局生效的。
  • Manage Plugins:插件管理,即在这里安装、更新、卸载插件
  • Configure System:一些基本的系统配置
  • Manage Users:用户管理,比如用户的新增、删除等操作

Configure System

一些基本的系统配置如图:
在这里插入图片描述
如果有安装插件,【Configure System】也会显示插件的一些基本信息,有些插件数据就可以在这里配置。

系统公告

如果想提醒每一个进入Jenkins平台的人员一些注意事项,可以通过【Configure System】的System Message进行配置
在这里插入图片描述
如果想使用HTML的内容,需要安装支持HTML的插件,在【Configure Global Security】中,将Markup Formatter切换到HTML,然后回来【Configure System】,编辑System Message的HTML内容

规范项目名称

【Configure System】中,勾选Restrict project naming,选择“Pattern”,在Name Pattern中设置正则匹配规则,Description中进行描述,点击“Save”进行保存后,创建项目时项目名称就必须符合指定的规则了
在这里插入图片描述

项目内配置

Discard old builds定时清理构建数据

项目在创建并构建后,会有持续的构建,这些构建数据都会被缓存起来,但是项目是不断的更新的,有一些旧的构建数据就没必要还保留了,减少空间资源的占用。
在这里插入图片描述

Source Code Management源码管理

源码可以通过git、svn等工具进行管理,我们需要安装对应的插件,然后配置源码远程仓库地址、登录帐号、分支信息等。源码的git、svn插件只是在Jenkins和Jenkins所在主机间作为一个桥梁,让Jenkins可以通过调用主机的命令行去下载源码,所以主机需要安装对应的代码管理工具,比如git

大部分项目是通过git进行源码管理的,插件安装Git
在这里插入图片描述
在项目的Source Code Management中配置远程仓库信息,其中登录帐号信息的可以有多种方式:

  • Username with password
  • SSH Username with private key
  • Secret file
  • Secret text
  • Certificate

常用的是Username with password和SSH Username with private key
勾选Git后,点击Credentials下的Add添加帐号信息
在这里插入图片描述
Username with password
在这里插入图片描述
SSH Username with private key
这个需要在远程仓库中配置SSH公钥数据,至于生成私钥公钥的步骤网上有教程,Gitee上也有,这里就不具体说明了:
在这里插入图片描述
在这里插入图片描述

Build Triggers构建触发器

Build Triggers,即如何触发构建,触发构建的方式总体有2种:手动触发和自动触发
手动触发就是人为去触发构建,即自己去点击构建按钮
在这里插入图片描述
自动构建就是Jenkins自己去触发构建,但是达到什么条件它才触发构建,是我们要进行设置的

定时触发构建Build periodically

定时触发构建即Jenkins按照指定的时间自动构建,在Build Triggers的Build periodically处设置触发时间
在这里插入图片描述

Build periodically设置时间是有格式的:
MINUTE HOUR DOM MONTH DOW

  • MINUTE:分钟,数值为0-59,表示在第几分钟
  • HOUR:一天中的小时,数值为0–23,表示在一天中的几点触发
  • DOM:一个月内的天数,数值为1–31,表示在每月的几号触发
  • MONTH:月份,数值为1–12,表示在哪个月触发
  • DOW:一周的天数,数值为0-7,0和7都表示周日,1、2、3、4、5、6表示周一、二、三、四、五、六。即表示周几触发

相关格式和数值了解之后,还有一些英文符号:

  • *:表示匹配任意值,即都满足,如果对字段的所有值都要满足的时候,就可以使用
  • M-N:取值区间,表示连续的从M到N,即M-N之间的数值都需要
  • */X:间隔区间,表示间隔X的时间段去执行
  • M-N/X:从M开始,每隔X,直到N结束
  • A,B,...,Z:枚举,就是在A、B…Z中的时候触发

练习:

题目答案
每天晚上20点整自动执行0 20 * * *
每周一0点15分开始执行15 0 * * 1
每周一、三、五晚上8点整执行0 20 * * 1,3,5
每周一到周五晚上8点整执行0 20 * * 1,2,3,4,5
或0 20 * * 1-5
一周内每隔2天的晚上8点整执行0 20 * * */2
每月1号23点15分执行15 23 1 * *
2周执行一次,在周一3点开始执行0 3 * * 1-1/2
每天16点到23点,隔3h执行一次0 16-23/3 * * *

将内容填写进去后,移除光标,会显示自动构建的时间安排:
在这里插入图片描述
如果想看自己的配置是否符合预期,可以在cron模拟网站上看看预期情况:crontab.guru/

在这里插入图片描述

定时触发构建一般用在定时任务或自动化执行的情况下,是一定会去构建(或执行)项目的。

定时检查更新Poll SCM

一般情况下,开发在实现了一部分代码,并可以整合的时候,就合并到远程仓库上去,Jenkins定时检查并更新服务器代码。避免开发一次性提交太多代码导致冲突,也能让测试人员尽早介入测试,越早发现问题成本越低。团队开发中,会规定开发在某个时间前更新迭代的代码(比如下班前更新功能开发完成的代码),让开发养成及时更新代码的习惯,避免后面因为代码量过大导致部分代码被遗漏的情况。
定时检查是在项目中的【Build Triggers】下的Poll SCM下配置的,配置规则与Build periodically的一致,两者的区别是:Build periodically是定时去构建,Poll SCM是定时去检查代码有没有更新,有更新才构建,无更新就不构建
在这里插入图片描述

Build Steps构建步骤

一般情况下,部署代码不仅仅是将代码上传到服务器指定目录那么简单,前面的例子是因为tomcat服务不用重启就可以访问到更新的html,有些服务是需要执行代码才会更新,比如java应用、python应用。这个时候就可以通过Build Setps配置执行命令,让Jenkins通过本地或远程服务器的命令行工具去执行命令。一般情况下是在远程服务器上执行命令,以下通过例子进行实践
以前面的例子(Jenkins+tomcat)为基础,在Jenkins构建时,生成time.html,显示当前时间,并能通过tomcat web服务进行访问
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

Build Environment构建环境配置

Build Environment可以设置构建前后的环境配置,比如构建前将服务关闭,或者构建前安装某些指定的第三方库之类的。
在这里插入图片描述

因为Build Steps也可以进行构建后的环境配置,所以Build Environment一般用来进行构建前的环境配置。
我们以【Build Steps构建步骤】中的例子为基础,在构建前生成一个pre.html文件,也是保存当前时间,并等待2秒后在进行下一步工作
在这里插入图片描述

访问pre.html和time.html,结果如下:
在这里插入图片描述

我们看【Build Steps】和【Build Environment】的配置,2者基本上都是SSH Publishers配置,从这里可以看出来,【Build Steps】和【Build Environment】基本上配置是一样的,只是执行顺序上有差别。

Post-build Actions构建后操作

Post-build Actions,一般是指在构建完成后的操作,比如邮件通知相关人员构建结果之类、或者触发自动化跑批执行等。这一部分依赖于插件,后面的章节会有实践涉及到这一部分,这里就不详细讲解了。

Logo

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

更多推荐