第1章 shared-library工作模式
1.1 sharedLibrary工作模式介绍
基本上每个项目的构建过程都是一样的，能改动的地方不多，检代码，做CI，构建，镜像推送，部署，后面发消息
比如发消息是每个项目都要用的，可以抽象成方法
用groovy去开发sharelibrary，这个库有很多公告逻辑
library如何去工作。DRY就是don’t repeat yourself
实际运用中，jenkins会把library的实际定义公共功能添加到构建目录中
之前是这么写的，retry（2）执行两次，这里就没有什么错误判断，处理异常的逻辑
devops就是我们创建的一个共享库，buildimage也就是公共的方法，所以可以把一些处理异常的放在公共的方法里
比如这样的逻辑
第2章 Groovy项目语法实践
2.1 开发环境搭建
安装jdk
配置环境变量
第一个环境变量java home
第二个环境变量，classpath，这个值是固定的
新建一个
测试一下
安装groovy
只需要做一个解压
同时path路径下也需要bin目录加进去
安装idea
快捷方式，关联文件
30天试用
jenkins的sharelibrary，用groovy来写，选择jdk1.8版本
选择groovy库
选择放在哪个目录里
现在项目就创建好了
验证能否使用，创建groovy的脚本
现在是可以跑的
2.2 Groovy基本语法实践（上）
library的代码结构，src，vars两个目录
这个j是代表java的
groovy是java派系的，但是偏向脚本式的语言
起一个jenkins-share-library
可以再建立一个目录
test目录下建立脚本
就有正常打印
可以定义一个方法
创建一个package
创建一个groovy
new就是创建类里面的实例
可以定位到sayhi在哪里
现在定义三个方法。this其实就是返回类的自己
让saybye return一个值
init是返回this这个类，所以可以调用任何方法
异常处理，这样会出错
改造成不报错，try，catch一个exception
2.3 Groovy基本语法实践（下）
执行看一下
导入类
timecatrgory.plus（加）new date当前时间的基础上，getseconds秒，也就是在当前时间基础上+15秒
break是可以跳出循环的
倒计时
这个可以应用在，kubectl创建deployment的时候，要去实时检测创建是否成功，不能一直等待看他是否成功，把时间设置5分钟，一直去检测，5分钟到了，就退出监测
安装groovy的时候没带，这个是groovy外部解析yaml文件比较好用的包
这里就有包了
准备一个读的yaml文件
复制到这里
取里面的值
kind就是这一个值
metadata name
现在就读取到了
打印spec replicas
第3章 library与jenkins集成
3.1 Library与Jenkins集成
jenkins怎么去和刚才写的library做集成
先创建一个package
第一个hello把内容初始化进去，把前面传来的参数放到this对象
要在jenkins使用library，需要先配置jenkins
创建项目
把一个目录推送到仓库里
创建一个.gitgnore,让一些目录不提交到gitlab上
已经关联到git仓库了
已经推送过去了
现在去jenkins配置一下library地址
**name library名字
default version jenkins里要去找仓库的默认版本（master分支）
**
scm管理器就是git
现在有了library，jenkinsfile就简化了
devops从哪里来的就需要建立目录
创建vars目录下有一个devops的脚本，也就是vars这个文件其实就是暴露library使用的入口。在devops去实现对src里方法的调用，也就支持下面对jenkinsfile的方法调用了
上面的方法就是devops最初调用的方法，返回值就是hello.groovy的对象，就可以在jenkinsfile做一个连续的调用
把新家的文件提交到仓库里
就是为了打通jenkinsfile的调用关系
现在就进行调度了
也就是在jenknsfle里就可以调用library了，代码构建，服务部署，消息推送都可以实现在library里
第4章 library实现镜像构建及推送
4.1 Library集成docker镜像构建
用library正式实现镜像构建推送的功能
想要在jenkinsfile里调用就需要在var是下定义方法，可以给默认值，镜像是repo+tag两个参数，dockerfile路径
以前构建docker镜像的方法
但是通常有默认值的放在后面，排一下序
上面的只是一个入口，真正去执行的docker构建还需要放在上面的实现脚本里，新建一个Docker.groovy。
传递的参数都放到this里
现在去做一个构建，在groovy脚本里可以通过sh方法调用shell命令，变量是要在${}里引用的
build写好了，那么就需要写如何调用了
加一个push操作
提交到git仓库
jenkins添加一个docker harbor凭据
加了一个dockerimage的
第一个参数repo，默认用git仓库的commitid 作为tag
上下文就是目录
调用docker命令返回的是docker对象
提交一下构建任务自动触发
执行docker login
执行docker build
4.3 丰富构建通知逻辑
之前的原版jenkinsfile
try异常，目的是执行三次看看是否成功
但是每次错误都会抛出异常，看看如何去优化
优化try逻辑，尝试三次，成功打印成功过，错误打印一次错误信息
通知giltab端构建任务及状态。也就是下面这个部分
这里加一个build，可以知道是在build步骤出错的
之前的是做的消息拼接，每次都需要拼接就可以做成公用的
就是去实现一个方法的问题
放到了BUILD_TASK环境变量里，只不过是通过一个接收参数的方式
在Docker.groovy里去调用新的类
每次都调用一个buildmessage
在这里加，就不需要每一个都new了
这里就可以直接用this.message了
push和login都需要把buildmessage方法加进去
改造一下jenkinsfile，推送到钉钉里
提交到gitlab上
blue ocean查看步骤
push也加入了判断成功与否
加一个env
提交一下library
这里出现的传参错误
提交代码
看到详细就成功了
目前的jenkinsfile里只是去做一个docker的构建，加上一个push，
第5章 library集成k8s服务部署
5.1 library实现自动部署简单版
之前的部署就是把镜像版本替换，然后进行部署
要现在devops里添加一个deploy部署方法
然后下src模块里加上实现
getobjects，获取一个deploy实例，下面开始去部署
这里赋值一个值
实例化一个buildmessage
return出去就OK了
push也改一下，改成双引号
在jenkinsfile里加上stage
到blueocen看一下
start可能写错了
这里是start
但是这里是deploy
改成start
这里少了目录文件
加上/*
这样就成功了
5.2 library实现自动部署优化版（上）
简单的版本只是去部署，还没有去检测部署状态，到底是成功还是失败没有检测
人工检查的思路
这是一个deployment
先把pod列表找出来
第二步，看这个pod是否running
查看部署的副本数和running是否达标
第一个难点是去做循环检测，多少分钟内一直去检测，类似定时器
如何通过library去实现
可以去解析拿到deployment里面的值
可以用label app=myblog过滤
如何检测pod状态
-o输出格式，jsonpath json的一个路径
.点好就是整个json文件
items就取到了数组第0项
status字段的phase属性
3.查看上述running pod数，是否和myblog的deployment中定义的repipas副本数一致
如果有多个pod，就需要遍历item列表确保每个状态值都是正常的
写一个计时器5分钟，5分钟不通过超时失败退出了，
这三个逻辑其实是在这个里，连续ready次数大于5次才认为更新deploy状态成功
如果readycount不满足，还没有超过5分钟，就休息5秒继续检测
5.3 library实现自动部署优化版（下）
是不是等待成功检测的过程，如果是true就去读代码workloadfilepath
观察pod的状态，正常来才去执行更新状态
否则就去执行else逻辑
这里可以直接readfile去读取文件内容，如果没有kind，那么这个yaml文件就不合法，抛出异常。
kind放到workloadtype
这个monitordeployment只是针对判断deployment，其他还需要自己写
查看monitordeployment如何实现
5分钟超时，就认为pod不正常，printcontainerlogs打印container日志
printcontainerlogs是如何实现的，namespace是从yaml文件里拿的
monitordeployment下半部分，没超时去做循环检测，去获取pod的json文件就是去读每个pod的状态内容，连续三次成功才去更新状态是成功的
否则状态0，打回原形，查看pod状态，这些都可以在jenkins看到，有异常就去更新失败
解析之后是一个json对象
循环检测，联系3次，也就是10秒钟去检测
重点是查看每个pod的状态、
现在服务没有不可用的
有不可用的肯定是false
下面就是检测pod
传一个参数，是否检测
、deployment文件路径
提交library代码
再提交jenkinsfile
循环检测和倒计时是很重要的
执行成功
这里还处于一个创建中的状态
通过一个label的方式去查找
还处于创建的时候，继续往下走
一个副本的时候，会有同一时间两个pod都在running的时候
第6章 library实现即使消息推送
6.1 手写library集成消息通知逻辑框架
消息通知也可以放到library去实现
比如想要直接调用一个library的方法，不在jenkins去实现
在library去实现，成功和失败都需要通知
有title，有项目名称
有用微信的，有email，需要通用，加个参数receiver
、比如传一个wechat
先搭一个框架，传一些参数，credentialsid，title
新建一个notification类
上面只是实现了一个类，真正实现一个通知还需要写方法
这里进行一个调用
jenkins里去调用
现在要区分成功还是失败，不用return给前面了，直接调用即可
jenkisnfile就可以这么写了
定义消息，失败和成功的消息
查看这几个参数
再实现把message传过去，定义一个方法
、
这里要去获取构建地址，构建分支的一些信息
拼接了一些项目名称，gitlog
有了这些拼成的msg，就可以发送消息，根据不同的receiver发送消息
这里实现一个失败消息，成功消息发送
再jenkinsfile里调用
这里实现了一个消息组装
6.2 library优化dingTalk消息通知
查看dingtalk和wechat如何去实现
建立一个dingtalk类，但是没必要用shell来实现了
token放在这里
生成的message信息，
validresponsecodes发送http请求的返回码
这里还是生成一个markdown格式
new一个dingtalk，然后markdown就可以了
wechat的就类似dingtalk的就行
httprequest不是默认的，是需要插件实现的
代码提交
修改jenkinsfile
提交一下jenkinsfile
已经在构建执行了
传递的错误参数是failure
提交一下
notification里生成了消息的内容
但是链接没有
这是定义了，没有加链接
、
markdown的语法，可以中括号，括起来
这就是期望的链接
第一次使用的时候需要加一个换行
遍历拼接
、
提交
持续构建中
返回res
消息通知
第7章 library集成代码扫描
7.1 library集成代码扫描
直接去执行代码扫描，等待3秒返回结果
检测的时候有一个version概念
有时候可以不等待检测结果，可以给一个开关
现在去建立sonar的类
这样就拿到version，commitid
这样就实现动态version变化
是否需要等待，然后成功或者失败
没有找到scan
提交一下
提交一下
不想检测就false，前面的空值会自动帮你获取version
对应上面的version
这里少了一次调用
提交一下
scan开始运行了
可以根据自己情况加扫描，不然有些太苛刻
新的检测
加入扫描成功
整个过程是ok的
支付宝扫一扫
微信扫一扫
.png)
.png)
