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

一、平滑发布与灰度发布

**什么叫平滑：**在发布的过程中不影响用户的使用，系统不会因发布而暂停对外服务，不会造成用户短暂性无法访问；

**什么叫灰度：**发布后让部分用户使用新版本，其它用户使用旧版本，逐步扩大影响范围，最终达到全部更新的发布方式；

灰度发布与平滑发布其实是关联的。当服务器的数量只有一台的时候，不存在灰度发布，一旦发布了就是所有用户都更新了，

所以这个时候只有平滑发布。当服务器数量大于一台的时候，只要每台服务器都能达到平滑发布的方式，然后设定好需要

发布的服务器占比数量，就可以实现灰度发布了。

单台服务器的平滑发布模式：

单机状态下，应用的持续服务主要依靠Nginx的负载均衡及自动切换功能；

为了能够切换应用，需要在服务器中创建两个相同的独立应用，分配两个不同的端口，

例如:app1,端口801; app2,端口802；

在Nginx中，将app1,app2作为负载均衡加载：

复制代码

    upstream myapp{
          server 127.0.0.1:801; //app1
          server 127.0.0.1:802; //app2
    }

    然后设置代理超时为1秒，以便在某个应用停止时及时切换到另一个应用：
server {
    listen 80;
    server_name localhost;
    location /{
    proxy_pass http://myapp;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout       1;
    proxy_read_timeout          1;
    proxy_send_timeout          1;
    }
}
    以上内容写在单独的配置文件中：/vhost/pub/pub_app.conf
    在nginx.conf里包含进去：
    include /vhost/*.conf;

现在系统会均衡地分配用户访问app1与app2。

接下来我们进行平滑发布，我们先把app1停止，然后将新版本发布到app1中：

复制代码

    步骤1： 准备发布app1配置文件
    新做一个配置文件 pub_app1_down.conf,内容中把app1停止掉：
    upstream myapp{
          server 127.0.0.1:801 down; //app1
          server 127.0.0.1:802; //app2
    }
    
    将这个文件内容覆盖掉在原有的pub_app.conf
    cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf


    步骤2：停止app1应用
    平滑重新加载一下nginx: 
    service nginx reload
    或者：
    /usr/local/nginx/sbin/nginx -s reload

    此时所有的请求都转到了app2了；

    步骤3：更新app1
    现在可以通过各种方式来更新应用了，例如：压缩包方式：
    wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
    unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
    其中：-o:不提示的情况下覆盖文件；-d:指定解压目录
    
    步骤3.5 内部测试
    如果需要的话，可以在这一步对app1进行内部测试，以确保应用的正确性；

    步骤4：准备发布app2配置文件；
    此时app1已经是最新版本的文件了，可以切换到app1来对外，

    创建一个新的nginx配置文件:pub_app2_down.conf，设置为app1对外,app2停止即可：
    
    upstream myapp{
          server 127.0.0.1:801; //app1
          server 127.0.0.1:802 down; //app2
    }

    将这个文件内容覆盖掉在原有的pub_app.conf
    cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf

    步骤5：切换到app1新版本应用 
    平滑重新一下nginx: 
    service nginx reload
    或者：
    /usr/local/nginx/sbin/nginx -s reload

    此时所有的请求都转到了app1了，新版本开始运行；

    步骤6：更新app2
    与第3步一样，解压就可以了，这里可以省去下载过程
    unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar

    步骤7：恢复app1,app2同时对外：
    cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
    
    平滑重新一下nginx: 
    service nginx reload
    或者：
    /usr/local/nginx/sbin/nginx -s reload

    至此，整个应用都已经更新。

    将各步骤中的脚本汇总一下：

    [pub.sh]
    #============ 平滑发布 v1.0 ===============
    #step 1
    cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf
    
    #step 2
    service nginx reload
    
    #step 3
    wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
    unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
    
    #step 4
    cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf
    
    #step 5
    service nginx reload
    
    #step 6
    unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
    
    #step 7
    cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
    service nginx reload
    #============ 平滑发布 v1.0  ===============    

    备注：也可以充分利用nginx的宕机检测，省去步骤1，2，4，5，7；
    简化后的脚本如下：

    [pub_mini.sh]
    #======== 简化版脚本 =============
    wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
    unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar

    unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
    #========= 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存储库中的应用程序代码库，并在一个名为的文件中指定构建，测试和部署脚本，该文件[这里是代码003]位于存储库的根路径中。

在此文件中，您可以定义要运行的脚本，定义包含和缓存依赖项，选择要按顺序运行的命令以及要并行运行的命令，定义要部署应用程序的位置，以及指定是否将要自动运行脚本或手动触发任何脚本。熟悉GitLab CI / CD后，您可以在配置文件中添加更多高级步骤。

要向该文件添加脚本，您需要按照适合您的应用程序的顺序组织它们，并且这些脚本符合您希望执行的测试。要想象可视化过程，请假设您添加到配置文件中的所有脚本与您在计算机终端上运行的命令相同。

将.gitlab-ci.yml配置文件添加到存储库后，GitLab将检测到它并使用名为GitLab Runner的工具运行脚本，该工具与终端类似。

脚本被分组到作业中 ，它们一起组成一个管道。.gitlab-ci.yml文件的极简主义示例可以包含：

复制代码

before_script:
  - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - 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，您需要熟悉[这里是代码010]配置文件语法及其属性。

本文档介绍了GitLab CI / CD在GitLab页面范围内的概念，用于部署静态网站。虽然它适用于想要从头开始编写自己的Pages脚本的用户，但它也可以作为GitLab CI / CD设置过程的介绍。它涵盖了编写CI / CD配置文件的第一个常规步骤，因此我们建议您通读它以了解GitLab的CI / CD逻辑，并了解如何为任何应用程序编写自己的脚本（或调整现有脚本）。

有关GitLab的CI / CD配置选项的深入视图，请查看 [这里是代码011]完整参考。

6、GitLab CI / CD功能集

使用Auto DevOps轻松设置应用程序的整个生命周期。
使用GitLab Pages部署静态网站。
将您的应用程序部署到不同的环境。
使用Review Apps预览每个合并请求的更改。
使用Container Registry开发安全的私有Docker镜像。
安装自己的GitLab Runner。
安排管道。

使用安全测试报告检查应用程序漏洞。

复制代码

具体实施参考：
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、上传 jdk11 tomcat jenkins.war
2、解压jdk
[root@jenkins ~]# yum -y install fontconfig 
[root@jenkins ~]# tar xf jdk-11.0.18_linux-x64_bin.tar.gz
3、解压tomcat
[root@jenkins ~]# tar xf apache-tomcat-8.5.50.tar.gz
4、拷贝并修改名称
[root@jenkins ~]# mv jdk-11.0.18/ /usr/local/java && mv apache-tomcat-8.5.50 /usr/local/tomcat
5、处理环境变量
[root@jenkins ~]# vim /etc/profile.d/java.sh
TOMCAT_HOME=/usr/local/tomcat
JAVA_HOME=/usr/local/java
PATH=$TOMCAT_HOME/bin:$JAVA_HOME/bin:$PATH
export TOMCAT_HOME JAVA_HOME PATH
[root@jenkins ~]# source /etc/profile.d/java.sh
6、上传jenkins
[root@jenkins ~]# rm -rf /usr/local/tomcat/webapps/*
[root@jenkins ~]# cp jenkins.war /usr/local/tomcat/webapps/
7、启动tomcat，并页面访问
[root@jenkins ~]# startup.sh

访问 ip:8080

为了安全考虑，首先需要解锁Jenkins，请在/var/lib/jenkins/secrets/initialAdminPassword中查看文件。

在Jenkins服务器上查询管理员密码

一个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 插件安装缓慢问题

复制代码

vim ~/.jenkins/hudson.model.UpdateCenter.xml
http://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json



vim ~/.jenkins/updates/default.json
% s/www.google.com/www.baidu.com/g
% s/updates.jenkins.io/download/mirrors.tuna.tsinghua.edu.cn/jenkins/g


旧版： http://updates.jenkins-ci.org/download 替换成 https://mirrors.tuna.tsinghua.edu.cn/jenkins 
新版：https://updates.jenkins.io/download 替换成 https://mirrors.tuna.tsinghua.edu.cn/jenkins 

修改完以后，重启Jenkins服务再输入密码，继续安装，速度贼快。