(CICD)自动化构建打包、部署(Jenkins + maven+ gitlab+tomcat) ...

打印 上一主题 下一主题

主题 989|帖子 989|积分 2967

一、平滑发布与灰度发布

**什么叫平滑:**在发布的过程中不影响用户的使用,系统不会因发布而暂停对外服务,不会造成用户短暂性无法访问;
**什么叫灰度:**发布后让部分用户使用新版本,别的用户使用旧版本,逐步扩大影响范围,终极达到全部更新的发布方式 ;
灰度发布与平滑发布其实是关联的。当服务器的数量只有一台的时候,不存在灰度发布,一旦发布了就是所有用户都更新了,
以是这个时候只有平滑发布。当服务器数量大于一台的时候,只要每台服务器都能达到平滑发布的方式,然后设定好需要
发布的服务器占比数量,就可以实现灰度发布了。
单台服务器的平滑发布模式:
单机状态下,应用的持续服务主要依赖Nginx的负载均衡及自动切换功能;
为了可以大概切换应用,需要在服务器中创建两个雷同的独立应用,分配两个差别的端口,
例如:app1,端口801; app2,端口802;
在Nginx中,将app1,app2作为负载均衡加载:
  1.     upstream myapp{
  2.           server 127.0.0.1:801; //app1
  3.           server 127.0.0.1:802; //app2
  4.     }
  5.     然后设置代理超时为1秒,以便在某个应用停止时及时切换到另一个应用:
  6. server {
  7.     listen 80;
  8.     server_name localhost;
  9.     location /{
  10.     proxy_pass http://myapp;
  11.     proxy_set_header Host $host;
  12.     proxy_set_header X-Real-IP $remote_addr;
  13.     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  14.     proxy_connect_timeout       1;
  15.     proxy_read_timeout          1;
  16.     proxy_send_timeout          1;
  17.     }
  18. }
  19.     以上内容写在单独的配置文件中:/vhost/pub/pub_app.conf
  20.     在nginx.conf里包含进去:
  21.     include /vhost/*.conf;
复制代码
​ 现在系统会均衡地分配用户访问app1与app2。
​ 接下来我们进行平滑发布,我们先把app1停止,然后将新版本发布到app1中:
  1.     步骤1: 准备发布app1配置文件
  2.     新做一个配置文件 pub_app1_down.conf,内容中把app1停止掉:
  3.     upstream myapp{
  4.           server 127.0.0.1:801 down; //app1
  5.           server 127.0.0.1:802; //app2
  6.     }
  7.    
  8.     将这个文件内容覆盖掉在原有的pub_app.conf
  9.     cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf
  10.     步骤2:停止app1应用
  11.     平滑重新加载一下nginx:
  12.     service nginx reload
  13.     或者:
  14.     /usr/local/nginx/sbin/nginx -s reload
  15.     此时所有的请求都转到了app2了;
  16.     步骤3:更新app1
  17.     现在可以通过各种方式来更新应用了,例如:压缩包方式:
  18.     wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
  19.     unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
  20.     其中:-o:不提示的情况下覆盖文件;-d:指定解压目录
  21.    
  22.     步骤3.5 内部测试
  23.     如果需要的话,可以在这一步对app1进行内部测试,以确保应用的正确性;
  24.     步骤4:准备发布app2配置文件;
  25.     此时app1已经是最新版本的文件了,可以切换到app1来对外,
  26.     创建一个新的nginx配置文件:pub_app2_down.conf,设置为app1对外,app2停止即可:
  27.    
  28.     upstream myapp{
  29.           server 127.0.0.1:801; //app1
  30.           server 127.0.0.1:802 down; //app2
  31.     }
  32.     将这个文件内容覆盖掉在原有的pub_app.conf
  33.     cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf
  34.     步骤5:切换到app1新版本应用
  35.     平滑重新一下nginx:
  36.     service nginx reload
  37.     或者:
  38.     /usr/local/nginx/sbin/nginx -s reload
  39.     此时所有的请求都转到了app1了,新版本开始运行;
  40.     步骤6:更新app2
  41.     与第3步一样,解压就可以了,这里可以省去下载过程
  42.     unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
  43.     步骤7:恢复app1,app2同时对外:
  44.     cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
  45.    
  46.     平滑重新一下nginx:
  47.     service nginx reload
  48.     或者:
  49.     /usr/local/nginx/sbin/nginx -s reload
  50.     至此,整个应用都已经更新。
  51.     将各步骤中的脚本汇总一下:
  52.     [pub.sh]
  53.     #============ 平滑发布 v1.0 ===============
  54.     #step 1
  55.     cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf
  56.    
  57.     #step 2
  58.     service nginx reload
  59.    
  60.     #step 3
  61.     wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
  62.     unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
  63.    
  64.     #step 4
  65.     cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf
  66.    
  67.     #step 5
  68.     service nginx reload
  69.    
  70.     #step 6
  71.     unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
  72.    
  73.     #step 7
  74.     cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
  75.     service nginx reload
  76.     #============ 平滑发布 v1.0  ===============   
  77.     备注:也可以充分利用nginx的宕机检测,省去步骤1,2,4,5,7;
  78.     简化后的脚本如下:
  79.     [pub_mini.sh]
  80.     #======== 简化版脚本 =============
  81.     wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
  82.     unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
  83.     unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
  84.     #========= over ===========
复制代码
多台服务器平滑发布模式:
有了单台平滑发布模式的底子,多台服务器就简单了。
每台服务器当作应用进行发布就可以了,由于nginx有宕机自动检测功能,
只需要在每台服务器上先停止发布,然后更新文件,再启动就可以了;
如果选择部分的服务器进行更新,那就是灰度了。
二、介绍 CI / CD

在本文档中,我们将概述持续集成,持续交付和持续部署的概念,以及GitLab CI / CD的介绍。
1、为什么要 CI / CD 方法简介

软件开发的一连方法基于自动实行脚本,以最大限度地减少在开发应用步调时引入错误的可能性。重新代码的开发到部署,它们需要较少的人为干预甚至根本不需要干预。
它涉及在每次小迭代中不停构建,测试和部署代码更改,从而减少基于有缺陷或失败的先前版本开发新代码的时机。
这种方法有三种主要方法,每种方法都根据最适合您的策略进行应用。 Devops
持续集成(Continuous Integration, CI): 代码归并,构建,部署,测试都在一起,不停地实行这个过程,并对结果反馈。
持续部署(Continuous Deployment, CD): 部署到测试情况、预生产情况、生成情况。
持续发布(Continuous Delivery, CD): 将终极产品发布到生成情况、给用户使用。

1、持续集成

思量一个应用步调,其代码存储在GitLab中的Git存储库中。开发职员每天多次推送代码更改。对于每次推送到存储库,您都可以创建一组脚本来自动构建和测试应用步调,从而减少向应用步调引入错误的可能性。
这种做法被称为持续整合 ; 对于提交给应用步调的每个更改 - 甚至是开发分支 - 它都是自动且一连地构建和测试的,确保所引入的更改通过您为应用步调建立的所有测试,指南和代码合规性尺度。
GitLab本身就是使用持续集成作为软件开发方法的一个例子。对于项目的每次推送,都会有一组脚本来检查代码。
2、持续交付

持续交付是持续集成的一个步骤。您的应用步调不仅在推送到代码库的每个代码更改时都构建和测试,而且,作为一个额外的步骤,它也会一连部署,只管部署是手动触发的。
此方法可确保自动检查代码,但需要人工干预才能手动并策略性地触发更改的部署。
3、持续部署

持续部署 也是持续集成的又一步,雷同于持续交付。差别之处在于,您不必手动部署应用步调,而是将其设置为自动部署。完全不需要人工干预就可以部署您的应用步调。
2、GitLab CI / CD简介

GitLab CI / CD是GitLab内置的强大工具,答应您将所有一连方法(持续集成,交付和部署)应用于您的软件,而无需第三方应用步调或集成。
3、GitLab CI / CD 的工作原理

要使用GitLab CI / CD,您只需要一个托管在Git存储库中的应用步调代码库,并在一个名为的文件中指定构建,测试和部署脚本,该文件.gitlab-ci.yml位于存储库的根路径中。
在此文件中,您可以界说要运行的脚本,界说包含和缓存依赖项,选择要按次序运行的命令以及要并行运行的命令,界说要部署应用步调的位置,以及指定是否将要自动运行脚本或手动触发任何脚本。认识GitLab CI / CD后,您可以在设置文件中添加更多高级步骤。
要向该文件添加脚本,您需要按照适合您的应用步调的次序组织它们,而且这些脚本符合您希望实行的测试。要想象可视化过程,告假设您添加到设置文件中的所有脚本与您在盘算机终端上运行的命令雷同。
将.gitlab-ci.yml设置文件添加到存储库后,GitLab将检测到它并使用名为GitLab Runner的工具运行脚本,该工具与终端雷同。
脚本被分组到作业中,它们一起组成一个管道。.gitlab-ci.yml文件的极简主义示例可以包含:
  1. before_script:
  2.   - apt-get install rubygems ruby-dev -y
  3. run-test:
  4.   script:
  5.     - ruby --version
复制代码
该before_script属性将在运行任何内容之前为您的应用步调安装依赖项,而且调用 的 作业run-test将打印当前系统的Ruby版本。它们都构成了在每次推送到存储库的任何分支时触发的管道
GitLab CI / CD不仅可以实行您设置的作业,还可以显示实行过程中发生的情况,如您在终端中看到的那样:

您可以为应用创建策略,GitLab会根据您界说的内容为您运行管道。您的管道状态也由GitLab显示:

末了,如果出现任何标题,您可以轻松 回滚所有更改:

4、根本CI / CD工作流程

这是GitLab CI / CD如何适用于通用开发工作流程的一个非常简单的示例。
假设您已在一个标题中讨论过代码实现,并在本地处理惩罚您提出的更改。将提交推送到GitLab中长途存储库中的功能分支后,将触发为项目设置的CI / CD管道。通过这样做,GitLab CI / CD:


  • 运行自动脚本(次序或并行)到:

    • 构建并测试您的应用。
    • 使用“评论应用”预览每个归并请求的更改,如您所见localhost。

一旦您对实行感到满意:


  • 让您的代码颠末审核和答应。
  • 将功能分支归并到默认分支。

    • GitLab CI / CD会自动将更改部署到生产情况中。

  • 末了,如果出现标题,您和您的团队可以轻松地将其回滚。

GitLab CI / CD可以大概做得更多,但这个工作流程体现了GitLab跟踪整个过程的本领,而无需任何外部工具来交付您的软件。而且,最有用的是,您可以通过GitLab UI可视化所有步骤。
5、首次设置 GitLab CI / CD

要开始使用GitLab CI / CD,您需要认识.gitlab-ci.yml设置文件语法及其属性。
本文档介绍了GitLab CI / CD在GitLab页面范围内的概念,用于部署静态网站。固然它适用于想要从头开始编写本身的Pages脚本的用户,但它也可以作为GitLab CI / CD设置过程的介绍。它涵盖了编写CI / CD设置文件的第一个通例步骤,因此我们建议您通读它以了解GitLab的CI / CD逻辑,并了解如作甚任何应用步调编写本身的脚本(或调整现有脚本)。
有关GitLab的CI / CD设置选项的深入视图,请查看 .gitlab-ci.yml完整参考。
6、GitLab CI / CD功能集



  • 使用Auto DevOps轻松设置应用步调的整个生命周期。
  • 使用GitLab Pages部署静态网站。
  • 将您的应用步调部署到差别的情况。
  • 使用Review Apps预览每个归并请求的更改。
  • 使用Container Registry开发安全的私有Docker镜像。
  • 安装本身的GitLab Runner。
  • 安排管道。
  • 使用安全测试陈诉检查应用步调漏洞。
    1. 具体实施参考:
    2. https://segmentfault.com/a/1190000016069906
    复制代码
三、Jenkins CI/CD

1、 Jenkins CI/CD 流程图


阐明:这张图轻微更形象一点,上线之前先把代码git到版本仓库,然后通过Jenkins 如Java项目通过maven去构建,这是在非容器之前,典范的自动化的一个版本上线流程。那它有哪些标题呢?
如:它的测试情况,预生产情况,测试情况。会存在肯定的兼容性标题 (情况之间会有肯定的差异)

阐明:它这里有一个docker harbor 的镜像仓库,通常会把你的情况打包为一个镜像,通过镜像的方式来部署。
Jenkins持续集成01—Jenkins服务搭建和部署
2、介绍 Jenkins

1、Jenkins概念

Jenkins是一个功能强大的应用步调,答应持续集成和持续交付项目,无论用的是什么平台。这是一个免费的源代码,可以处理惩罚任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技能。Jenkins是一种软件答应持续集成。
2、Jenkins目的

① 持续、自动地构建/测试软件项目。
② 监控软件开放流程,快速标题定位及处理惩罚,提示开放效率。
3、特性

① 开源的java语言开发持续集成工具,支持CI,CD。
② 易于安装部署设置:可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署,可方便web界面设置管理。
③ 消息通知及测试陈诉:集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知,生成JUnit/TestNG测试陈诉。
④ 分布式构建:支持Jenkins可以大概让多台盘算机一起构建/测试。
⑤ 文件识别:Jenkins可以大概跟踪哪次构建生成哪些jar,哪次构建使用哪个版本的jar等。
⑥ 丰富的插件支持:支持扩展插件,你可以开发适合本身团队使用的工具,如git,svn,maven,docker等。
4、产品发布流程

产品设计成型 -> 开发职员开发代码 -> 测试职员测试功能 -> 运维职员发布上线
持续集成(Continuous integration,简称CI)
持续交付(Continuous delivery)
持续部署(continuous deployment)
3、安装Jenkins

1、安装JDK

​ Jenkins是Java编写的,以是需要先安装JDK,这里采用yum安装,如果对版本有需求,可以直接在Oracle官网下载JDK;也可本身编译安装。
2、安装Jenkins

  1. 1、上传 jdk11 tomcat jenkins.war
  2. 2、解压jdk
  3. [root@jenkins ~]# yum -y install fontconfig
  4. [root@jenkins ~]# tar xf jdk-11.0.18_linux-x64_bin.tar.gz
  5. 3、解压tomcat
  6. [root@jenkins ~]# tar xf apache-tomcat-8.5.50.tar.gz
  7. 4、拷贝并修改名称
  8. [root@jenkins ~]# mv jdk-11.0.18/ /usr/local/java && mv apache-tomcat-8.5.50 /usr/local/tomcat
  9. 5、处理环境变量
  10. [root@jenkins ~]# vim /etc/profile.d/java.sh
  11. TOMCAT_HOME=/usr/local/tomcat
  12. JAVA_HOME=/usr/local/java
  13. PATH=$TOMCAT_HOME/bin:$JAVA_HOME/bin:$PATH
  14. export TOMCAT_HOME JAVA_HOME PATH
  15. [root@jenkins ~]# source /etc/profile.d/java.sh
  16. 6、上传jenkins
  17. [root@jenkins ~]# rm -rf /usr/local/tomcat/webapps/*
  18. [root@jenkins ~]# cp jenkins.war /usr/local/tomcat/webapps/
  19. 7、启动tomcat,并页面访问
  20. [root@jenkins ~]# startup.sh
  21. 访问 ip:8080
复制代码

为了安全思量,起首需要解锁Jenkins,请在/var/lib/jenkins/secrets/initialAdminPassword中查看文件。

在Jenkins服务器上查询管理员密码
[root@centos7-1 ~]# cat /data/jenkins/secrets/initialAdminPassword
250d0360e2a149dbb7402f96a26945e2
② 选择需要安装的插件
选择默认保举即可,会安装通用的社区插件,剩下的可以在使用的时候再进行安装。

开始安装,由于网络原因,有一些插件会安装失败。

③ 设置Admin用户和密码


④ 安装完成

⑤ 登录Jenkins


安装插件:
gitlab
gitlab webhook
blue ocean
maven
Pipeline Maven
4、安装完后,简单的设置

1、系统设置

① 系统消息:Welcome to Jenkins~
② 全局属性—>情况变量,可根据本身的项目添加;如:gitlab:

③ 扩展邮件通知(用于之后项目构建后发送邮件)

④ 邮件设置
管理监控设置—>系统管理员邮件地址:along@163.com,要和下面的用户名同等;
邮件通知,设置如下:可以点击测试,是否设置乐成

2、全局工具设置

如果你持续集成需要用的哪些工具,就需要在这里添加设置;后边持续集成中,将会详细讲解;
这里只举例:添加JDK工具
点击新增—> 取消自动安装 ---->然后查询Jenkins服务器上JDK的路径,填写JAVA_HOME —> 保存即可

3、插件管理

这里有可更新、可选未安装插件、已安装插件;可以通过过滤快速查找

5、添加节点

   node 节点的作用
  

  • 分布式构建:通过添加多个节点,可以在多台盘算机上并行实行构建任务,从而加快构建速度和提高效率。节点可以是物理盘算机、虚拟机、云实例或容器等。
  • 扩展盘算本领:通过添加更多的节点,可以扩展Jenkins的盘算本领,使其可以大概处理惩罚更多的并发构建任务,从而适应不停增长的工作负载。
  • 平台兼容性:使用Node节点可以在差别的操作系统、差别的硬件平台上实行构建任务,以满足项目的特定需求。您可以设置节点以适应特定的操作系统、软件情况和工具链。
  • 隔离和安全性:将构建任务分配给独立的节点可以提供更好的隔离和安全性。节点之间相互独立,一个节点的故障或标题不会影响其他节点的工作。
  • 负载均衡:Jenkins可以根据节点的负载情况自动分配任务,从而实现负载均衡。这样可以更好地利用可用资源,并确保每个节点都能以最佳状态运行。
  1、准备节点

  1. 1、准备一台新的服务器并配置java环境
  2. 2、主节点添加凭据,并推送公钥
  3. 3、在node节点配置需要的工具
复制代码
2、系统设置


3、添加节点




4、检查节点


6、开始一个简单的项目

1、新建任务

输入一个项目名称,构建一个自由风格的软件项目

2、设置项目

(1)General
描述:test 本身随意添加;
显示名称:along 是Jenkins看到的项目名称;
其他更多的用法,后续再讲;

(2)源码管理(就是拉取代码的地方,可以选择git或SVN)
① 选择git,输入gitlab项目地址

② 点击Add添加凭据
选择SSH Username with pricate key,秘钥认证,输入私钥即可;
注:Jenkins服务器需在gitlab项目上有key

由于只是简单的示范,以是就只有这些简单的设置;
3、构建项目

(1)点击项目damo,立即构建

(2)可以点击#1,查询详细的控制台输出信息;

(3)在Jenkins服务器上认证
在这个目次下能找到本身拉取git的项目;证明项目乐成完成
[root@jenkins ~]# ls /data/jenkins/workspace/
damo damo@tmp
四、Jenkins+Maven+Gitlab+Tomcat 自动化构建打包、部署

1、情况需求

本帖针对的是Linux情况,Windows或其他系统也可借鉴。详细只讲述Jenkins设置以及整个流程的实现。


  • 1.JDK(或JRE)及Java情况变量设置,我用的是JDK1.8.0_144,网上帖子也许多,不赘述。
  • 2.Jenkins 持续集成和持续交付项目。
  • 3.现有项目及gitlab(SVN或本地路径也行)地址。
  • 4.maven工具及情况变量设置,用于构建和管理任何基于Java的项目。
  • 5.下载解压Tomcat,我用的是Tomcat8。
2、情况准备

1、安装服务

(1)安装JDK、Jenkins和gitlab
JDK yum安装和编译安装都可以;
gitlab 安装详见:gitlab 部署;
tomcat 安装详见:tomcat 服务部署
(2)mave安装
1、下载 maven 包
http://mirrors.cnnic.cn/apache/maven 选择本身需要的maven版本
  1. wget https://mirrors.cnnic.cn/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz
  2. tar -zxvf apache-maven-3.5.4-bin.tar.gz
复制代码
2、设置情况变量

(1)设置全局情况变量
vim /etc/profile.d/jenkins_tools.sh
  1. #JDK
  2. export JAVA_HOME=/usr/java/jdk1.8.0_144
  3. export JRE_HOME=${JAVA_HOME}/jre
  4. export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib
  5. export PATH=${JAVA_HOME}/bin:$PATH
  6. export TIME_STYLE='+%Y/%m/%d %H:%M:%S'
  7. #maven
  8. export MAVEN_HOME=/data/jenkins_tools/maven-3.5.4
  9. export PATH=${MAVEN_HOME}/bin:$PATH
复制代码
使情况变量生效
  1. source /etc/profile.d/jenkins_tools.sh
复制代码
(2)测试
  1. java -version
  2. java version "1.8.0_144"
  3. Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
  4. Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
复制代码
  1. $ mvn -version
  2. Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)
  3. Maven home: /data/jenkins_tools/maven-3.5.4
  4. Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: /usr/java/jdk1.8.0_144/jre
  5. Default locale: en_US, platform encoding: UTF-8
  6. OS name: "linux", version: "3.10.0-514.26.2.el7.x86_64", arch: "amd64", family: "unix"
复制代码
3、Jenkins工具、情况、插件设置

1、全局工具设置

系统管理—>全局工具设置
修改maven默认settings.xml文件,设置git、jdk、maven工具后保存(不要勾选自动安装)。


2、设置全局变量

系统管理—>系统设置—>全局属性

3、安装3个插件

系统管理—>插件管理
(1)Maven Integration plugin 安装此插件才能构建maven项目

(2)Deploy to container Plugin 安装此插件,才能将打好的包部署到tomcat上

(3) mvn设置国内源
4、创建一个Maven工程

1、构建maven项目


2、源码管理

填写git地址信息,添加认证凭据,详见Jenkins持续集成01—Jenkins服务搭建和部署

3、构建触发器,可以根据本身的业务需求定制

① Build whenever a SNAPSHOT dependency is built:检测到gitlab项目代码被重新构建后就触发;
② 轮询 SCM:*/2 * * * * ,每隔2分钟检查一次


4、打包前步骤,根据本身需求可以添加一些操作:如一些shell命令


5、build打包构建

① Root POM:指定pom.xml的文件路径(这里是相对路径)
② Goals and options:mvn的选项,构件参数

6、构建后操作

(1)选择deploy war to a container,部署到tomcat

(2)设置tomcat信息



  • WAR/EAR files:输入war包的相对路径,如我的war包在新建目次的target下
  • context path:输入部署tomcat的名称,就部署在webapps下的目次名
  • add container:增加容器,一样平常选tomcat 8X就可以。这里的username与password需要到tomcat的conf文件夹中的tomcat-users.xml修改。tomcat URL就是你希望把war包部署到的tomcat地点IP地址,末了面不需要再加斜杠/。
  • tomcat-users.xml中的用户名及密码默认是注释掉的,以是需要修改,也可以直接复制以下代码到之前。
  1.   <role rolename="tomcat"/>
  2.   <role rolename="role1"/>
  3.   <role rolename="manager-gui" />
  4.   <role rolename="manager-script" />
  5.   <role rolename="manager-status" />
  6.   <user username="tomcat" password="tomcat" roles="tomcat"/>
  7.   <user username="both" password="tomcat" roles="tomcat,role1"/>
  8.   <user username="role1" password="tomcat" roles="role1"/>
  9.   <user username="deploy" password="tomcat" roles="manager-gui,manager-script,manager-status" />
复制代码


  • 然后到tomcat下面webapps/manager/META-INF/context.xml 注销掉红色部分。由于默认tomcat不可以通过外部ip访问管理界面。肯定要启动Tomcat,不然等构建等时候会报拒绝连接
  1. <Context antiResourceLocking="false" privileged="true" >
  2.   <!--<Valve className="org.apache.catalina.valves.RemoteAddrValve"
  3.          allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />-->
  4.   <Manager sessionAttributeValueClassNameFilter="java\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
  5. </Context>
复制代码
(3)添加tomcat的凭据

7、设置邮件通知

增加构建后操作—>Editable Email Notification
使用邮件同事前,需要再系统设置中进行邮箱设置
(1)设置邮件信息

(2)设置邮件触发器triggers
默认触发器:Failure - Any 无论何时失败触发;加一个success作为测试;
修改收件人为:recipient list

到这里就设置完成了,点击构建从控制台查看输出信息即可
5、构建项目

1、立即构建


2、查看控制台输出

点击#1—>控制台输出;就能看到实行的整个过程

3、验证项目是否构建乐成

(1)乐成向上蓝色;失败即为红色

(2)在tomcat上查看项目

(3)收到项目构建乐成的邮件

五、jenkins + gitlab + nginx 自动部署(webhook)

构建新的项目

构建自由风格项目


源码管理

git 如何添加认证

构建触发器 gitlab-plugin gitlab-hook


要记载下上边的URL和认证密钥
切换到gitlab,找到对应的git库 点击setting --> Integrations ,填写以下内容,然后下拉点击 Add webhook

可能会报下列错误,这是新版本gitlab 的保护功能,禁止内网跳转,解决方法如下:

点击setting --> network 找到 Outbound requests

重复上列步骤添加 webhook。即可乐成。
测试:
六、Jenkins与Docker的自动化CI/CD流水线实践

Pipeline 有诸多优点,例如:


  • 项目发布可视化,明确阶段,方便处理惩罚标题
  • 一个Jenkins File文件管理整个项目生命周期
  • Jenkins File可以放到项目代码中版本管理
Jenkins管理界面

操作实例:Pipeline的简单使用



这里是比较重要的核心,构建流程

点击保存之后,立即构建

映像中平凡Jenkins构建方式步骤:

而pipeline 的构建流程:

pipeline有诸多优点:


  • 项目发布可视化,明确阶段,方便处理惩罚标题
  • 一个Jenkins File 文件管理整个项目生命周期
  • Jenkins File 可以放到项目代码中版本管理

一个Jenkins file 维护一个生命周期,就像写代码一样,只维护这个file文件就可以了。



小结:
Jenkins与kubernetes搭建CI/CD流水线有诸多好处:


  • Jenkins高可用
  • 自动伸缩
  • 情况隔离
  • 易维护
Maven插件:
Maven Integration plugin
Deploy to container Plugin
webhook插件:
gitlab-plugin
gitlab-hook
jenkins 插件安装缓慢标题

  1. vim ~/.jenkins/hudson.model.UpdateCenter.xml
  2. http://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
  3. vim ~/.jenkins/updates/default.json
  4. % s/www.google.com/www.baidu.com/g
  5. % s/updates.jenkins.io\/download/mirrors.tuna.tsinghua.edu.cn\/jenkins/g
  6. 旧版: http://updates.jenkins-ci.org/download 替换成 https://mirrors.tuna.tsinghua.edu.cn/jenkins
  7. 新版:https://updates.jenkins.io/download 替换成 https://mirrors.tuna.tsinghua.edu.cn/jenkins
  8. 修改完以后,重启Jenkins服务再输入密码,继续安装,速度贼快。
复制代码
代码中版本管理
[外链图片转存中…(img-FD9Gvysk-1716297681339)]
一个Jenkins file 维护一个生命周期,就像写代码一样,只维护这个file文件就可以了。
[外链图片转存中…(img-Y27e0Ib5-1716297681339)]
[外链图片转存中…(img-Aj0FTZuk-1716297681340)]
[外链图片转存中…(img-FvZ5XOk7-1716297681340)]
小结:
Jenkins与kubernetes搭建CI/CD流水线有诸多好处:


  • Jenkins高可用
  • 自动伸缩
  • 情况隔离
  • 易维护
Maven插件:
Maven Integration plugin
Deploy to container Plugin
webhook插件:
gitlab-plugin
gitlab-hook
jenkins 插件安装缓慢标题

  1. vim ~/.jenkins/hudson.model.UpdateCenter.xml
  2. http://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
  3. vim ~/.jenkins/updates/default.json
  4. % s/www.google.com/www.baidu.com/g
  5. % s/updates.jenkins.io\/download/mirrors.tuna.tsinghua.edu.cn\/jenkins/g
  6. 旧版: http://updates.jenkins-ci.org/download 替换成 https://mirrors.tuna.tsinghua.edu.cn/jenkins
  7. 新版:https://updates.jenkins.io/download 替换成 https://mirrors.tuna.tsinghua.edu.cn/jenkins
  8. 修改完以后,重启Jenkins服务再输入密码,继续安装,速度贼快。
复制代码
总结条记

http下载gitee直接下载
ssh的话需要在个人设置里面添加要拉去代码的服务器的公钥才可以
上传的话就要登录才可以

有新的项目之后,分支

添加课件 1.7.1
gitlab 设置:两核四G
xiaowang 前端
xiaoli 后端
牛马 管理
xiaohei 维护
jenkins安装及插件

设置从节点的时候,高级里面的java路径不需要输入

邮件发送失败? 在全局里面少了个点
https://gitee.com/hyunze/easy-springmvc-maven gitee的项目克隆
gitlab root Qq111111
jenkins admin 123456
gitee私家令牌:55ef1dd1aa15751956581e184907c995
本身下载的gitee的项目上传到gitlab之后需要更改pom文件的java版本号
当我修改了gitlab里面的java文件,文件名直接改了,我都不知道发生了什么,然后我去jenkins的服务器里面找到那个文件并改了名字才好了/root/.jenkins/workspace/maven-test1/src/main/java/spring/demo/service/D…
参数化构建
模版1 3 4 jenkins gitlab tomcat-java 没做完 先快照 2是node01

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

悠扬随风

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表