一、平滑发布与灰度发布

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

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

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

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

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

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

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

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

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

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

<code> 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存储库中的应用程序代码库，并在一个名为的文件中指定构建，测试和部署脚本，该文件<code>.gitlab-ci.yml位于存储库的根路径中。

在此文件中，您可以定义要运行的脚本，定义包含和缓存依赖项，选择要按顺序运行的命令以及要并行运行的命令，定义要部署应用程序的位置，以及指定是否将要自动运行脚本或手动触发任何脚本。熟悉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：

运行自动脚本（顺序或并行）到：

构建并测试您的应用。使用“评论应用”预览每个合并请求的更改，如您所见<code>localhost。

一旦您对实施感到满意：

让您的代码经过审核和批准。将功能分支合并到默认分支。

GitLab CI / CD会自动将更改部署到生产环境中。 最后，如果出现问题，您和您的团队可以轻松地将其回滚。

GitLab CI / CD能够做得更多，但这个工作流程体现了GitLab跟踪整个过程的能力，而无需任何外部工具来交付您的软件。而且，最有用的是，您可以通过GitLab UI可视化所有步骤。

5、首次设置 GitLab CI / CD

要开始使用GitLab CI / CD，您需要熟悉<code>.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。

安排管道。

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

具体实施参考：

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

<code>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服务器上查询管理员密码

[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、准备节点

<code>1、准备一台新的服务器并配置java环境

2、主节点添加凭据，并推送公钥

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版本

<code>wget https://mirrors.cnnic.cn/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz

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

2、配置环境变量

（1）配置全局环境变量

vim /etc/profile.d/jenkins_tools.sh

#JDK

export JAVA_HOME=/usr/java/jdk1.8.0_144

export JRE_HOME=${JAVA_HOME}/jre

export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib

export PATH=${JAVA_HOME}/bin:$PATH

export TIME_STYLE='+%Y/%m/%d %H:%M:%S'code>

#maven

export MAVEN_HOME=/data/jenkins_tools/maven-3.5.4

export PATH=${MAVEN_HOME}/bin:$PATH

使环境变量生效

source /etc/profile.d/jenkins_tools.sh

（2）测试

java -version

java version "1.8.0_144"

Java(TM) SE Runtime Environment (build 1.8.0_144-b01)

Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

$ mvn -version

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)

Maven home: /data/jenkins_tools/maven-3.5.4

Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: /usr/java/jdk1.8.0_144/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "linux", version: "3.10.0-514.26.2.el7.x86_64", arch: "amd64", family: "unix"

3、Jenkins工具、环境、插件配置