最新要闻

广告

手机

iphone11大小尺寸是多少？苹果iPhone11和iPhone13的区别是什么？

iphone11大小尺寸是多少？苹果iPhone11和iPhone13的区别是什么？

 警方通报辅警执法直播中被撞飞：犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞：犯罪嫌疑人已投案

家电

  1. 首页
  2. 移动通信
  3. 内容

【天天报资讯】K8S圣经12：SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布

来源：博客园

文章很长，持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录 博客园版为您奉上珍贵的学习资源 ：

免费赠送 :《尼恩Java面试宝典》持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备免费赠送 :《尼恩技术圣经+高并发系列PDF》，帮你 实现技术自由，完成职业升级， 薪酬猛涨！加尼恩免费领免费赠送 经典图书:《Java高并发核心编程（卷1）加强版》面试必备 + 大厂必备 +涨薪必备 加尼恩免费领免费赠送 经典图书:《Java高并发核心编程（卷2）加强版》面试必备 + 大厂必备 +涨薪必备 加尼恩免费领免费赠送 经典图书:《Java高并发核心编程（卷3）加强版》面试必备 + 大厂必备 +涨薪必备 加尼恩免费领

免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取


(资料图片仅供参考)

SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布

尼恩的技术社群中（50+），尼恩一直到指导大家面试， 指导大家做简历优化。

生产环境 ，如何进行SpringCloud+Jenkins+ K8s Ingress 灰度发布， 是很多小伙伴都没有实操过的难题。

但是，灰度实操，又是高级开发，和架构师的必须课。很多小伙伴，由于不懂灰度，不懂云原生，错失了高级开发或者架构师岗位，实在非常可惜。

所以，尼恩基于《K8S学习圣经》, 为大家系统化从原理到实操，介绍一下SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布。作为《K8S学习圣经》的12部分。

《K8S学习圣经》的组成

  • 第一部分：云原生(Cloud Native)的原理与演进
  • 第二部分：穿透K8S的8大宏观架构
  • 第三部分：最小化K8s环境实操
  • 第四部分：Kubernetes 基本概念
  • 第五部分：Kubernetes 工作负载
  • 第六部分：Kubernetes 的资源控制
  • 第七部分: SVC负载均衡底层原理
  • 第八部分: Ingress底层原理和实操
  • 第九部分： 蓝绿发布、金丝雀发布、滚动发布、A/B测试 实操
  • 第十部分： 服务网格Service Mesh 宏观架构模式和实操
  • 第十一部分： 使用K8S+Harber 手动部署 Springboot 应用
  • 第十二部分： SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布
  • 第十三部分： k8s springboot 生产实践（高可用部署、基于qps动态扩缩容、prometheus监控）
  • 第十四部分：k8s生产环境容器内部JVM参数配置解析及优化

米饭要一口一口的吃，不能急。

结合《K8S学习圣经》，尼恩从架构师视角出发，左手云原生+右手大数据 +SpringCloud Alibaba 微服务 核心原理做一个宏观的介绍。由于内容确实太多， 所以写多个pdf 电子书：

(1) 《 Docker 学习圣经 》PDF （V1已经完成）

(2) 《 SpringCloud Alibaba 微服务 学习圣经 》PDF （V1已经完成）

(3) 《 K8S 学习圣经 》PDF （coding…）

(4) 《 flink + hbase 学习圣经 》PDF （planning …）

以上学习圣经，并且后续会持续升级，从V1版本一直迭代发布。 就像咱们的《 尼恩 Java 面试宝典 》一样， 已经迭代到V60啦。

40岁老架构师尼恩的掏心窝： 通过一系列的学习圣经，带大家穿透“左手云原生+右手大数据 +SpringCloud Alibaba 微服务“ ，实现技术 自由 ，走向颠覆人生，让大家不迷路。

本PDF 《K8S 学习圣经》完整版PDF的 V1版本，后面会持续迭代和升级。供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

以上学习圣经的 基础知识是 尼恩的 《高并发三部曲》，建议在看 学习圣经之前，一定把尼恩的《 Java高并发三部曲 》过一遍，切记，切记。

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请从下面的链接获取：码云 或者 语雀

本部分目录（第12部分）

目录
  • SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布
    • 《K8S学习圣经》的组成
    • 本部分目录（第12部分）
    • 如何进行 SpringCloud+Jenkins+ K8s Ingress 灰度发布？
    • 回顾 Nginx-ingress 架构和原理
    • 灰度实操之前的准备
      • 部署和测试 stable 版本的 deployment 和 svc
      • 部署和测试 canary版本的 deployment 和 svc
    • 基于用户的灰度场景
      • 接下来，开始基于 用户的灰度实操
    • 基于权重的灰度场景
      • 基于权重的 Canary 规则
      • 基于权重的发布实操
    • 如何进行自动化灰度？
    • jenkins 安装和 pipeline 流水线的使用
      • 下载和启动 jenkins
      • 登录 jenkins
      • 使用 pipeline 插件
        • 安装 Pipeline 插件
      • pipeline 的 hello world
      • pipeline 语法介绍
      • Jenkins 插件 SSH Pipeline Steps
        • sshCommand 在远程节点上执行给定的命令并响应输出
        • sshGet 从远程主机获取文件或目录
        • sshPut 将文件或目录放入远程主机
        • sshRemove 删除远程主机上的文件或目录
        • sshScript 在远程节点上执行给定的脚本(文件)并响应输出
        • 结合 withCredentials 从 Jenkins 凭证存储中读取私钥
      • pipeline支持的指令
    • ingress 灰度发布流水线设计
      • CICD 流水线预览
      • step1：自动化的制品发布
        • 1、克隆 springboot代码项目到本地
        • 2、maven构建springboot代码项目
        • 3、构建docker镜像
        • 4、推送docker镜像到harber上，完成制品发布
      • step2：生产环境进行 A/B 测试
        • A/B 测试原理：
      • step3：生产环境进行 A/B 测试
      • step4：生产环境进行版本正式切换
    • 最后总结一下
    • 技术自由的实现路径：
      • 实现你的 架构自由：
      • 实现你的 响应式 自由：
      • 实现你的 spring cloud 自由：
      • 实现你的 linux 自由：
      • 实现你的 网络 自由：
      • 实现你的 分布式锁 自由：
      • 实现你的 王者组件 自由：
      • 实现你的 面试题 自由：

如何进行 SpringCloud+Jenkins+ K8s Ingress 灰度发布？

生产环境 ，如何进行SpringCloud+Jenkins+ K8s Ingress 灰度发布， 是很多小伙伴都没有实操过的难题。

但是，这些又是高级开发，和架构师的必须课。

在 Kubernetes 上的应用实现灰度发布，最简单的方案是引入官方的 Nginx-ingress来实现。我们通过部署两套 deployment 和 services，分别代表灰度环境和生产环境，通过负载均衡算法，实现对两套环境的按照灰度比例进行分流，进而实现灰度发布。

通常的做法是当项目打包新镜像后，通过修改 yaml文件的镜像版本，执行 kubectl apply的方式来更新服务。

如果发布流程还需要进行灰度发布，那么可以通过调整两套服务的配置文件权重来控制灰度发布，这种方式离不开人工执行。

那么，有没有一种方式能够实现逐步灰度呢？比如自动将灰度比例从 10% 权重提高到 100%，且并且出现问题秒级回退.

答案是肯定的，利用 jenkins 就能够满足此类需求。

本文，为大家介绍一下，SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布

回顾 Nginx-ingress 架构和原理

回顾一下 Nginx-ingress的架构和实现原理：

Nginx-ingress通过前置的 Loadbalancer类型的 Service接收集群流量，将流量转发至 Nginx-ingressPod 内并对配置的策略进行检查，再转发至目标 Service，最终将流量转发至业务容器。

传统的 Nginx需要我们配置 conf文件策略。

但 Nginx-ingress通过实现 Nginx-ingress-Controller将原生 conf配置文件和 yaml配置文件进行了转化，当我们配置 yaml文件的策略后，Nginx-ingress-Controller将对其进行转化，并且动态更新策略，动态 Reload Nginx Pod，实现自动管理。

那么 Nginx-ingress-Controller如何能够动态感知集群的策略变化呢？

方法有很多种，可以通过 webhook admission 拦截器，也可以通过 ServiceAccount 与 Kubernetes Api 进行交互，动态获取。

Nginx-ingress-Controller使用后者来实现。所以在部署 Nginx-ingress我们会发现 Deployment内指定了 Pod 的 ServiceAccount，以及实现了 RoleBinding ，最终达到 Pod 能够与 Kubernetes Api 交互的目的。

灰度实操之前的准备

部署一套稳定版本的 deployment 和 svc

然后再部署一套灰度版本的 deployment 和 svc

在进行流量的分发测试

部署和测试 stable 版本的 deployment 和 svc

kubectl apply -f app-service.yaml部署一下

访问一下

curl http://192.168.49.2:30808

部署和测试 canary版本的 deployment 和 svc

canary版本 的 deployment 和 svc

kubectl apply -f app-service.yaml部署一下

访问一下

curl http://192.168.49.2:30909

以上具体的实操过程， 请参见 尼恩的 《穿透云原生视频》

基于用户的灰度场景

简单的基于用户的发布场景， ingress 需要加上注解：

nginx.ingress.kubernetes.io/canary:"true"nginxingress.kubernetes.io/canary-by-header:"canary"

用户的Request Header 的值有一个 canary header，当 canary header的值：

当 设置为 always时，请求将会被一直发送到 Canary 版本；

当 设置为 never时，请求不会被发送到 Canary 入口；

对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。

具体如下图：

如果用户要自定义 Request Header 的值，必须与canary-by-header 注解(annotation ）一起使用。

这里的例子，使用 nginx.ingress.kubernetes.io/canary-by-header，自定义 Request Header 进行流量切分，适用于灰度发布以及 A/B 测试。

annotations:  kubernetes.io/ingress.class: "nginx"  nginx.ingress.kubernetes.io/canary: "true"  nginx.ingress.kubernetes.io/canary-by-header: "region"  nginx.ingress.kubernetes.io/canary-by-header-value: "beijing"

此灰度规则为：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。

如果按照的配置，

当 Request Header的 region 设置为 beijing时，请求将会被一直发送到 Canary 版本；

当 Request Header 没有 region，或者 设置为非 beijing时，请求不会被发送到 Canary 入口；

接下来，开始基于 用户的灰度实操

配置stable版本的ingress

配置canary版本的ingress

当我们访问的时候不带header，则只会访问stable版本应用，如下：

while sleep 1; do curl http://foo.bar.com/ | egrep flag; done

如果我们在访问的时候带上region: sichuan 的header，则只会访问到canary版本应用，如下：

while sleep 1; do curl http://foo.bar.com/ -H "region: beijing"  | egrep flag; done

以上具体的实操过程， 请参见 尼恩的 《穿透云原生视频》

基于权重的灰度场景

基于权重的 Canary 规则

使用 nginx.ingress.kubernetes.io/canary-weight注解：

基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。

权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。

权重为 100 意味着所有请求都将被发送到 Canary 入口。

基于权重的发布实操

(1)配置stable版本的ingress

同基于用户的灰度场景，这里不做赘述

(2)配置canary版本的ingress

具体如下。 源文件可以找尼恩获取。

(3) 启动 基于权重的灰度 ingress

(4)然后我们通过访问测试，效果如下：

while sleep 1; do curl http://foo.bar.com/ | egrep flag; done

以上具体的灰度实操过程， 请参见 尼恩的 《穿透云原生视频》

如何进行自动化灰度？

在生产环境，通过上面的手工命令，一行一行的执行是不现实的

需要借助自动化的流水线

jenkins 安装和 pipeline 流水线的使用

Jenkins pipeline是基于Groovy语言实现的DSL，用于描述流水线如何进行，包括编译、打包、部署、测试等等步骤

此处我们使用离线安装包方式安装/docker-compose 的方式安装

Jenkins 官网：https://www.jenkins.io

官方安装文档指导：https://www.jenkins.io/doc/book/installing/

下载和启动 jenkins

这里简单介绍一下 Jenkins 的本机部署方式.

一般都是下载一个 Jenkins 的 war, 修改配置文件中的 JDK 路径, 然后 service start 就可以正常使用了.

我们在服务器上执行如下命令进行jenkins可运行包下载

mkdir -p /usr/local/jenkinscd /usr/local/jenkins下载这个包 https://get.jenkins.io/war-stable/2.375.1/jenkins.war复制Jenkins war包到 安装目录cp /vagrant/chapter28/jenkins.2.375.1.war  .

找一个 start-jenkins.sh 脚本去启动jenkins。这个shell 和springboot的启动脚本一样，启动命令可以接参数start|restart|stop 分别标识启动，重启，停止服务

复制启动脚本到 安装目录cp /vagrant/chapter28/deploy_jenkins.sh .

脚本内容如下：

给启动脚本执行权限，并启动jenkins

chmod +x start-jenkins.shsh  start-jenkins start查看日志tail -f nohup.out

这种方式部署简单, 但是容易将我们的服务器环境变得十分复杂.

所以下面介绍本节docker-compose 搭建 Jenkins.

尼恩的环境，首先使用的这种方式。但是发现一个问题，新版本的 jenkins 需要依赖 jdk11， jkd8 不能用了

而尼恩的 公司有要求，一定要用jkd8

所以只能用 docker 安装 jenkins ，实现jdk的隔离。

docker-compose 编排文件 如下：

volumes:#Jenkins 工作目录,主要存储数据( /user/data/jenkins，安装后初始化密码也在此处 /secrets/initialAdminPassword ) - ./data:/var/jenkins_home"#将主机的Docker套接字装入容器中，这将允许Jenkins容器使用主机的Docker守护进程来构建映像并运行容器。 - "/var/run/docker.sock:/var/run/docker.sock"#容器内可共享宿主机的 docker- "/usr/bin/docker:/usr/bin/docker"#容器内享有 宿主机的docker-compose 环境- "/usr/local/bin/docker-compose:/usr/local/bin/docker-compose"

使用尼恩的一键启动shell脚本，一键启动

具体实操，请参见尼恩视频

首次登录需要查看初始化密码：( 挂载数据文件内可以查看 )

cat ./secrets/initialAdminPassword

需要修改插件的镜像源地址为

https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

具体的修改方式为，修改

修改后，重新启动，就可以从清华大学的插件镜像站，下载插件了

接下来访问 jenkins

登录 jenkins

查看启动日志,看到初始化管理员密码数据即表示启动成功，

copy对应的密码，通过ip+port方式进行访问，

上面shell 脚本中指定的端口为8980，我们在启动日志中也能够看到启动的端口为8090。

在浏览器中输入：http://cdh1:8980

终于看到jenkins的登录界面

输入密码后，安装插件点击选择插件来安装，然后取消掉几个默认安装的插件

插件安装完毕，有几个失败的，无所谓关键是 pipeline 插件安装好了就行

接下来，创建第一个管理员用户

全部填 admin

进行一下实例配置

保存后完成

使用 pipeline 插件

Jenkins Pipeline是一套插件，支持在Jenkins中实施和集成持续交付管道。pipeline是部署流水线，它支持脚本和声明式语法，能够比较高自由度的构建jenkins任务.个人推荐使用这种方式去构建jenkins。

Pipeline在Jenkins上增加了一套强大的自动化工具，支持从简单的持续集成到全面的CD管道的用例。通过对一系列相关任务建模，用户可以利用Pipeline的更多功能，如：

  • 可维护：管道是在代码中实现的，并且通常会被签入源代码管理，从而使团队能够编辑，审阅和迭代他们的交付管道。
  • 可能出现：在继续进行管道运行之前，管道可以选择停止并等待人员输入或批准。
  • 复杂场景：管道支持复杂的实际CD需求，包括分叉/连接，循环和并行执行工作的能力。
  • 可扩展性：Pipeline插件支持对其DSL的定制扩展 。

一次持续交付（CD）管道是从用户到版本控制软件的自动化表达。对软件的每一次改变（在源代码控制中提交）都会在发布过程中经历一个复杂的过程。

这个过程包括以可靠和可重复的方式构建软件，以及通过测试和部署的多个阶段来推进构建的软件（称为“构建”）。

Pipeline提供了一套可扩展的工具，用于通过管道域特定语言（DSL）语法将“简单到复杂”的交付管道使用“代码”建模 。

安装 Pipeline 插件

如果没有安装 Pipeline 插件，那么还需要单独安装 Jenkins Pipeline 插件

注意，默认 Jenkins 使用 https://updates.jenkins.io/update-center.json 下载并安装扩展，但是速度较慢。

我们可以修改为使用国内镜像站点，比如清华大学镜像站点：

1）Manage Jenkins / Manage Plugins / Advanced

2）Update Site / URL https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

3）Submit

https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

pipeline 的 hello world

pipeline是部署流水线，它支持脚本和声明式语法。

通过界面手动配置来配置CD过程，想要配置一些复杂度高的任务，只能选择自由风格的项目，通过选项等操作进行配置，让jenkins可以下载代码、编译构建、然后部署到远程服务器，这样显然是不方便管理和移植的。

pipeline可以创建一个jenkinsfile来申明一个任务，方便管理和移植。

接下来我们创建一个最简单的pipeline。

登录jenkins，点击创建item:

在流水线中选择hello world 生成代码：

以上便是一个最简单的流水线。

点击build now (立即构建)，jenkins任务开始执行，运行完成后点击查看执行记录：

在console output 中可以看到运行记录：

为了提高流水线的复用性以及便于流水线代码的管理，更多的是将pipeline的脚本在远程git仓库，当我们修改了远程仓库的流水线脚本，jenkins就会加载到最新的脚本执行。

在流水线配置中选择pipeline script from SCM:

按照提示配置好脚本git仓库地址，访问仓库的凭证，流水线脚本文件的名称（默认是Jenkinsfile），分支（默认是master）等。

配置完成后在仓库中添加文件Jenkinsfile把脚本提交并push， 最后执行任务，发现执行成功。

通过这个特性，我们可以把我们的流水线脚本和项目代码本身放到一个仓库中管理，达到多版本控制并和代码版本统一的效果。

如果我们编写jenkinsfile需要语法提示相关的编辑器，可以使用jenkins官方提供的vscode插件Jenkins Pipeline Linter Connector 。

使用idea Groovy 也能提示部分语法。

idea 设置jenkinsfile 语法提示方法 settings > editor > File Types > Groovy 新增一列Jenkinsfile.

pipeline 语法介绍

jenkins pipeline有2种语法：脚本式（Scripted）语法和声明式（Declar-ative）语法。

pipeline插件从2.5版本开始同时支持两种语法，官方推荐的是使用申明式语法，

在这里也只对申明式语法进行介绍。

申明式语法demo:

pipeline {    agent any    stages {        stage("pull") {            steps {                echo "拉取代码"            }        }    stage("build") {            steps {                echo "构建代码"            }        }    }}

声明式语法中，以下结构是必须的，缺少就会报错：

  • pipeline：固定语法，代表整条流水线
  • agent 执行代理人：指定流水线在哪执行，

​ 默认any即可，也可以指定在docker、虚拟机等等里执行

  • environment 环境变量，类似全局变量
environment {  //构建执行者  BUILD_USER = "" }
  • triggers 构建触发器，Jenkins自动构建条件
triggers{//每3分钟判断一次代码是否有变化pollSCM("H/3 * * * *")}

  • stages：流水线阶段集合节点

    该节点中至少有一个stage

  • stage：流水线的阶段节点

    每个阶段中至少包含一个steps

  • steps：执行步骤集合

    每个集合至少包含一个step。

  • step: 执行步骤。

下面是一个比较大的例子

pipeline {    //代理，通常是一个机器或容器    agent any         //环境变量，类似全局变量    environment {        //构建执行者        BUILD_USER = ""    }         //构建触发器，Jenkins自动构建条件    triggers{        //每3分钟判断一次代码是否有变化        pollSCM("H/3 * * * *")    }     stages {        //构建阶段        stage("Build") {            //使用build user vars插件，获取构建执行者            steps {                wrap([$class: "BuildUser"]) {                    script {                        //将构建执行者注入到环境变量中，方便最后通知使用                        BUILD_USER = "${env.BUILD_USER}"                    }                }                /* 从Bitbucket上拉取分支                * @url git地址                * @branch 分支名称                * @credentialsId Jenkins凭证Id，用于远程访问                */                git(url: "https://demo@bitbucket.org/demo/demo.git", branch: "master", credentialsId: "Bitbucket")                //执行maven打包                //-B --batch-mode 在非交互（批处理）模式下运行(该模式下,当Mven需要输入时,它不会停下来接受用户的输入,而是使用合理的默认值);                //打包时跳过JUnit测试用例，                //-DskipTests 不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下                //-Dmaven.test.skip=true，不执行测试用例，也不编译测试用例类                sh "npm install && npm run build"            }        }                 //部署阶段        stage("Deliver") {            steps {                //执行脚本                    sh """                        cd /var/lib/jenkins/workspace/demo/                        tar -cvf dist.tar.gz ./dist                        """            }        }        stage("SSH") {            steps {                script {                                   def remote = [:]                  remote.name = "test"                  remote.host = "192.168.12.12"                    remote.allowAnyHosts = true                    withCredentials([usernamePassword(credentialsId: "192.168.12.12", passwordVariable: "password", usernameVariable: "username")]) {                        remote.user = "${username}"                        remote.password = "${password}"                    }                    sshCommand remote: remote, command: "pwd"                    sshRemove remote: remote, path: "/usr/share/nginx/html/demo/dist"                    sshPut remote: remote, from: "/var/lib/jenkins/workspace/demo/dist.tar.gz", into: "/usr/share/nginx/html/test-monitor/"                    sshCommand remote: remote, command: "cd /usr/share/nginx/html/demo/ && tar -xvf ./dist.tar.gz"                }            }        }    }}

Jenkins 插件 SSH Pipeline Steps

安装插件 SSH Pipeline Steps, 以支持 跨机器执行脚本。

此插件可通过SSH在远程服务器执行命令和传输文件。

sshCommand 在远程节点上执行给定的命令并响应输出

node {  def remote = [:]  remote.name = "root"  remote.host = "cdh1"  remote.user = "root"  remote.password = "vagrant"  remote.allowAnyHosts = true  stage("Remote SSH") {    sshCommand remote: remote, command: "ls -lrt"    sshCommand remote: remote, command: "for i in {1..5}; do echo -n \"Loop \$i \"; date ; sleep 1; done"  }}

sshGet 从远程主机获取文件或目录

node {  def remote = [:]  remote.name = "test"  remote.host = "test.domain.com"  remote.user = "root"  remote.password = "password"  remote.allowAnyHosts = true  stage("Remote SSH") {    sshGet remote: remote, from: "abc.sh", into: "abc_get.sh", override: true  }}

sshPut 将文件或目录放入远程主机

node {  def remote = [:]  remote.name = "test"  remote.host = "test.domain.com"  remote.user = "root"  remote.password = "password"  remote.allowAnyHosts = true  stage("Remote SSH") {    writeFile file: "abc.sh", text: "ls -lrt"    sshPut remote: remote, from: "abc.sh", into: "."  }}

sshRemove 删除远程主机上的文件或目录

node {  def remote = [:]  remote.name = "test"  remote.host = "test.domain.com"  remote.user = "root"  remote.password = "password"  remote.allowAnyHosts = true  stage("Remote SSH") {    sshRemove remote: remote, path: "abc.sh"  }}

sshScript 在远程节点上执行给定的脚本(文件)并响应输出

node {  def remote = [:]  remote.name = "test"  remote.host = "test.domain.com"  remote.user = "root"  remote.password = "password"  remote.allowAnyHosts = true  stage("Remote SSH") {    writeFile file: "abc.sh", text: "ls -lrt"    sshScript remote: remote, script: "abc.sh"  }}

结合 withCredentials 从 Jenkins 凭证存储中读取私钥

为了提高安全性,可以用Credentials Plugin屏蔽用户名密码。

def remote = [:]remote.name = "node-1"remote.host = "10.000.000.153"remote.allowAnyHosts = truenode {    withCredentials([sshUserPrivateKey(credentialsId: "sshUser", keyFileVariable: "identity", passphraseVariable: "", usernameVariable: "userName")]) {        remote.user = userName        remote.identityFile = identity        stage("SSH Steps Rocks!") {            writeFile file: "abc.sh", text: "ls"            sshCommand remote: remote, command: "for i in {1..5}; do echo -n \"Loop \$i \"; date ; sleep 1; done"            sshPut remote: remote, from: "abc.sh", into: "."            sshGet remote: remote, from: "abc.sh", into: "bac.sh", override: true            sshScript remote: remote, script: "abc.sh"            sshRemove remote: remote, path: "abc.sh"        }    }}

pipeline支持的指令

pipeline的基本结构满足不了现实多变的需求。所以，jenkins pipeline通过各种指令（directive）来丰富自己。

Jenkins pipeline支持的指令有：

  • environment：用于设置环境变量，可定义在stage或pipeline部分
  • tools：可定义在pipeline或stage部分。它会自动下载并安装我们指定的工具，并将其加入PATH变量中
  • input：定义在stage部分，会暂停pipeline，提示你输入内容
  • options：用于配置jenkins pipeline本身的选项，比如options { retry(3) }表示，当pipeline失败时再重试2次。options指令可定义在stage或pipeline部分
  • parallel：并行执行多个step。
  • parameters：与input不同，parameters是执行pipeline前传入的一些参数
  • triggers：用于定义执行pipeline的触发器
  • when：当满足when定义的条件时，阶段才执行。

ingress 灰度发布流水线设计

在使用ingress 进行灰度之前，直接使用service+deployment的方式进行灰度。这种场景下，可以 通过不同的镜像（含deployment）来进行灰度大概的流程如下：

  • 发布canary版本应用进行测试
  • 测试完成将canary版本替换成stable版本
  • 删除canary版本的ingress配置
  • 删除老的stable版本

整个过程中，对于已经部署好的deployment是不能直接修改labels标签的。

所以，在canary版本测试完成后，还要更新stable版本的镜像。当然，可以使用滚动更新的方式去完成。那我们流水线可以这样设计，如下：

在使用ingress 进行灰度之后，灰度测试通过之后，就使用灰度镜像作为new stable 镜像使用，不需要重新的打包镜像，但是在发布期间，线上同时会存在旧的 old stable 和 canary 两套镜像， 虽然浪费一些资源，但是好处随时可以回退。

其实尼恩告大家，版本的发布是惊心动魄， 回退的概率非常大。 同时存在两套版本，实现s级回退， 也是一件非常爽的事情。

在使用ingress 进行灰度之后，灰度的流程，可以变得更加灵活，更加丰富，更加稳健。

在使用ingress 进行灰度 ，总体流程为3部分，大致如下：

CICD 流水线预览

为了实现以上目标，我们设计了以下持续部署流水线。

AB测试和灰度，部署流水线主要实现了以下几个步骤：

1、自动化的制品发布，通过gitlab进行自动化打包之后，通过钩子方法触发流水线，打包镜像到harber仓库2、生产环境进行 A/B 测试3、生产环境自动灰度发布（自动进行4次逐渐提升灰度比例）4、生产环境进行版本正式切换

step1：自动化的制品发布

自动化的制品发布流程图：

从 Gitlab 提交代码到自动触发持续集成的步骤：

1、提交代码后触发持续集成，自动构建镜像2、镜像构建完成后，自动推送镜像到制品库3、触发持续部署

在gitlab上， 有回调jenkins的hook 链接设置，设置之后，可以触发 jenkins 的 自动化制品构建流水线。

这里的制品就是docker 镜像。 制品的 仓库就是harber。

模拟的 制品构建流水线如下

具体的步骤，大概如下：

1、克隆 springboot代码项目到本地

stage("Clone") {    echo "1.Clone Stage"        git url: "https://gitee.com/xujk-27400861/springboot-dubbo.git"            script {            build_tag = sh(returnStdout: true, script: "git rev-parse --short HEAD").trim()        }    echo "${build_tag}"}

2、maven构建springboot代码项目

编写脚本，因为我们要编译构建项目的子项目，所以需要跳转到子目录去构建

stage("执行构建") {    container("maven")    {        sh "mvn --version"            sh "pwd"            sh """cd provider/             mvn clean package -DskipTests"""            //sh "mvn package"            echo "构建完成"    }}

provider/为项目子目录，我们要编译的项目；-DskipTests参数，表示跳过代码测试

3、构建docker镜像

编写脚本，构建docker镜像；

stage("Build") {    echo "3.Build Stage"        container("docker") {        sh "docker -v"            sh "pwd"            sh """cd /home/jenkins/agent/workspace/linetest/provider/             ls            docker build -t xjk27400861/springbootapp:${build_tag} ."""            }}

4、推送docker镜像到harber上，完成制品发布

编写脚本，推送docker镜像；

stage("Push") {    echo "4.Push Docker Image Stage"        container("docker") {        sh "docker  login --username=xjk27400861 -p xujingkun@123"            sh "docker  push xjk27400861/springbootapp:${build_tag}"    }}

具体的实操，请参见 尼恩的云原生视频。

step2：生产环境进行 A/B 测试

进行 A/B 测试流程如下：

进行 A/B 测试时，只有 Header 包含 location=beijing 可以访问新版本，其他用户访问生产环境仍然为旧版本。或者header可以设置为其他的参数。

这里要注意，可以把参与 A/B 测试 的用户，在数据库里边进行配置， 前端能带有AB测试的标志。

AB测试手动触发，流水线比较简单。

发布AB测试的ingress之后， 流量分发的架构图如下：

A/B 测试原理：

部署了两套应用，一套旧的稳定的stable应用，一套新版canary 灰度应用。

新旧的应用都配置了ingress相同的host。

而新的ingress还添加了注解canary:true 代表开启使用灰度发布

kubernetes.io/ingress.class: "nginx"nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "region"nginx.ingress.kubernetes.io/canary-by-header-value: "beijing"

只有 Header 包含 location=beijing 的流量是会从new-ingress这个ingress进来访问新版本应用。

其他流量从old-ingress的ingress去访问老版本的应用。

具体的实操，请参见 尼恩的云原生视频。

step3：生产环境进行 A/B 测试

在AB测试通过之后，可以结束ab测试的ingress，通过 流水线结束。

接下来，开始灰度，一共四轮灰度

第一次灰度：新版本 30% 的灰度比例，此时访问生产环境大约有 30% 的流量进入新版本灰度环境：

30s 后自动进行第二轮灰度：新版本 60% 的灰度比例：

60s 后自动进行第三轮灰度：新版本 90% 的灰度比例：

60s 后自动进行第四轮灰度：新版本 100% 的灰度比例：

每一轮灰度，可以两种方式步进：

（1） 人工确认：是否自动灰度发布， 流水线上设置确认按钮， 单击确认进入下一步

（2） 定时步进：流水线上设置时间，比如每轮间隔 30s

本案例中，配置了定时步进方式，渐进式进行，每次持续 30s 后自动进入下一个灰度阶段。

灰度过程中的流量架构图，大致如下：

在不同的灰度阶段，会发现请求新版本出现的概率越来越高。

灰度流水线的示意图如下;

如果过程当中需要回退，可以结束流水线，然后执行 灰度撤销流水线。灰度撤销流水线的示意图，大致如下jenkins 流水线上，更多的是shell脚本的编写

由此可见，shell脚本的编写能力，是多么重要

具体的实操，请参见 尼恩的云原生视频。

step4：生产环境进行版本正式切换

灰度版本稳定一段时间之后， 进行善后的工作

把老的稳定版本去掉， 完成生产环境进行版本正式切换

流程图如下：

步骤：

1、把stable-service指向访问cannary-deloyment

应为canary 已经足够稳定了

2、删除canary-ingress

不需要 灰度的ingress 了

3、删除canary-service

不需要灰度的svc 了

4、删除stable-deployment

不需要 老的stable-deployment 了

canary deployment 已经足够稳定了，已经编程新的stable deployment

具体的实操，请参见 尼恩的云原生视频。

最后总结一下

上面的灰度流程， 很多环节也是手动的，需要人工参与的。

如果不需要手动参与，可以使用argo-rollouts结合argocd进行灰度发布，argo-rollouts自定义了一套CRD用于控制发布流程，可以省去很多手动操作过程，argocd是基于gitops实现的一套软件，便于我们进行CD控制，也提供了UI面板进行操作。

但是线上发布， 是非常重要，非常谨慎的一个操作。

而且很容易出问题，及时有预发布环境， 也容易出问题， 常常出现紧急回退的场景。

在尼恩亲手尽力的几百次发布过程中， 回退是大概率事件。

常常进行版本回退。

所以，不建议使用全自动的发布流程，全自动无值守，往往意味着高风险。

一句话：背锅的滋味，不好受呀。

技术自由的实现路径：

实现你的 架构自由：

《吃透8图1模板，人人可以做架构》

《10Wqps评论中台，如何架构？B站是这么做的！！！》

《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》

《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》

《100亿级订单怎么调度，来一个大厂的极品方案》

《2个大厂 100亿级 超大流量 红包 架构方案》

… 更多架构文章，正在添加中

实现你的 响应式 自由：

《响应式圣经：10W字，实现Spring响应式编程自由》

这是老版本 《Flux、Mono、Reactor 实战（史上最全）》

实现你的 spring cloud 自由：

《Spring cloud Alibaba 学习圣经》 PDF

《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》

实现你的 linux 自由：

《Linux命令大全：2W多字，一次实现Linux自由》

实现你的 网络 自由：

《TCP协议详解 (史上最全)》

《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》

实现你的 分布式锁 自由：

《Redis分布式锁（图解 - 秒懂 - 史上最全）》

《Zookeeper 分布式锁 - 图解 - 秒懂》

实现你的 王者组件 自由：

《队列之王： Disruptor 原理、架构、源码 一文穿透》

《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》

《缓存之王：Caffeine 的使用（史上最全）》

《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》

实现你的 面试题 自由：

4000页《尼恩Java面试宝典 》 40个专题

关键词：