2020/05/15 k8s结合CICD持续交付及集中管理配置1

5.1 回顾

之前使用的了dashboard,把dashboard插件做为k8s核心附件出现的,k8s有4个核心 组件,CNI网络插件,容器之间跨节点通信,flannel,coredns主要用于服务发现,把服务名称和对应的集群网络地址,自动粘合起来
traefik作为暴露服务,把服务暴露到集群外面,核心资源ingress,通过ingress,把traefik安装进去,traefik本身是简化版的nginx和go脚本,go语言脚本是自动发现你的ingress的yaml,资源配置清单是如何变化的,变化以后应用到k8s集群里,k8s就能发现yaml变化 了,规则变化还是后端调度流量方式变化了,通过不同的ingress的yaml配置,traefik有自动发现 ,发现以后就能应用并动态生效

最后的核心插件是dashboard,图形界面,用来管理核心资源,三种资源管理方式之一:(陈述式,声明式,图形化),dashboard是在恰当的时候管理k8s集群。
是基于rbac进行鉴权的管理插件,rbac就是基于角色的访问控制(用户账户,服务账户,角色(role和cluster role),权限(分某个api组,里面有某些资源)通过给角色赋予权限,用户账户绑定角色)
常用的两个版本1.8.3和1.10.1,区别就是8.3有skip按钮,强制跳过rbac认证,直接用本身默认的service account的 token令牌


如果dashboard要用到令牌,就要使用https来通信,需要自签证书,放到nginx里,用户访问的时候访问https,先到nginx把证书卸载掉,然后proxy pass给traefik ingress控制器,监听在了每个宿主机的81端口,交付了dashboard,就获得了一个完整的k8s集群

kubeadm默认是1年,所以要修改k8s集群,还需要改源码,重新编译

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第1张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第2张图片
Dubbo微服务的架构,registry注册中心(zookeeper),有提供者(部署到k8s里,注册到注册中心)和消费者(订阅注册中心的方法,rpc),消费者在使用的时候,就是像在本地调用一样,还有moniter去观察组件消费者和提供者工作是否正常

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第3张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第4张图片
交付zookeeper和jenkins,jenkins是作为一个持续集成的组件,帮助我们把源代码从版本控制中心git,也可以用svn,通过配置和编译,把源代码通过编译变成了一个可执行的二进制码,
jenkins主要作用就是编译好代码,打成docker镜像,并提交到私有仓库里,这就是交付jenkins主要做的三件事,拉代码,编译,放到仓库里

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第5张图片
主要是让jenkins和harbor仓库进行通信,推送镜像
在这里插入图片描述
让jenkins使用docker引擎,在jenkins里安装客户端
在这里插入图片描述
jenkins的docker客户端是和宿主机服务端通过socket进行通信
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第6张图片
第一需要有docker镜像,第二把镜像扔到harbor仓库,k8s本身要从私有仓库里拉镜像,第三是要准备资源配置清单,根据服务特点给相应的资源配置清单,必须要包含的是一个pod控制器,这个pod控制器是有daemonset,可能是deployment也可能是其他的,必然包含pod控制器,和svc和ingress。
准备好资源配置清单,就应用到了k8s集群里

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第7张图片
需要安装这个blue ocean
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第8张图片

5.2 二进制安装maven

只有fully up and running才证明jenkins完全起来了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第9张图片
jenkins的容器还是比较耗费资源,普罗米修斯随便就吃20G内存
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第10张图片
验证jenkins可用,需要做一些事情
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第11张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第12张图片
用web shell的方式到jenkins容器里
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第13张图片
是否以root方式启动,时区是否是东8区,是否连接到宿主机的docker引擎
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第14张图片
跟21主机上所有容器列出的一模一样
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第15张图片
还要去验证是否能登陆harbor仓库
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第16张图片
这个是dockerfile里就指定的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第17张图片
用git用户去连接 test连接 -T指的是test测试连接,不是真正的连接
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第18张图片
下面要安装 部署maven,是用来编译java程序,maven是阿帕奇基金会开源的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第19张图片
一般jdk1.7,用maven 3
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第20张图片
选择编译好的,选择清华大学的源
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第21张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第22张图片
这些都是已经归档的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第23张图片
binaries二进制包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第24张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第25张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第26张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第27张图片
jdk版本指的是jenkins里的jdk版本
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第28张图片
看一下版本

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第29张图片
先把目录创建出来

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第30张图片
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第31张图片
把那一层取消
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第32张图片
在这里插入图片描述
要对maven做初始化配置,源设置成国内的,这样拉jar包就直接在阿里云里拉了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第33张图片
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第34张图片
可以在jenkins _home里可以安装你想要的工具
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第35张图片
docker镜像就是挂载了宿主机上
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第36张图片

5.3 dubbo微服务底包镜像制作

build jenkins,实际要get docker,要用到国外的源,所以build的时候要失败很多次,实在不行就直接用软件包,这就是一个docker镜像
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第37张图片
这是已经把get docker整合进去了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第38张图片
这样存到harbor里,再去build就快了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第39张图片
load到docker引擎里,一层层加载,aufs
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第40张图片
在这里插入图片描述
在这里插入图片描述
找到这个images,就需要打一个标签,push到仓库
在这里插入图片描述
修改dockerfile
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第41张图片
到infra仓库里
就是build不过去,只能采用这种方法
在这里插入图片描述
只需要把底包加载进来,然后,12,3,4,5,6,

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第42张图片
maven3也可以指定不同 的jdk来编译
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第43张图片
在这里插入图片描述
下载jdk
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第44张图片
解压到当前目录
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第45张图片
这个jdk就进来了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第46张图片
如果maven不能用1.8jdk,需要到目录里一个脚本

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第47张图片
java_home可以定义成当前jdk1.7,也就是执行maven命令的时候,用的是1.7,而没有用jenkins容器里的1.8,可以去手动的用maven指定jdk,只要去编辑maven脚本即可
**加粗样式**
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第48张图片
这只是演示,然后把安装的jdk删除
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第49张图片
下一步交付Dubbo微服务提供者和消费者,需要准备一个底包,找到一个合适 运行时环境底包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第50张图片
debian系列的底包
在这里插入图片描述
把镜像pull下来
在这里插入图片描述
也可以run 这个sh的时候指定源是阿里云
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第51张图片
有一个jre7 ,有一个jre8,可以直接用
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第52张图片
在这里插入图片描述
下载下来的镜像应该打个tag,放到harbor镜像里
在这里插入图片描述

在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第53张图片
下载底包,调整时区,add confg.yml监控的,jmx_javaagent是收集jvm的信息,这个相当于采集jvm的jar包,一个采集jvm的客户端
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第54张图片
下载下来
在这里插入图片描述
一般架构师就是通过监控jvm来调优。首先vi config.yml
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第55张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第56张图片
这里相当于指定工作目录是opt/project.dir

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第57张图片
docker默认运行的启动脚本
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第58张图片
entrypoint.sh 定义了三个变量
在这里插入图片描述
这个变量是当前docker运行的环境变量有一个JAR_BALL的变量,赋值到shell脚本里,k8s的yaml配置清单里,可以传一个变量。这就是云原生的思想,docker不是信息孤岛,可以通过k8s配置清单,环境变量的方式来给容器做一些初始化的操作
在这里插入图片描述
这是java的一些启动参数
在这里插入图片描述
这是docker的ip,在k8s里叫pod IP
在这里插入图片描述
这是12346是m_port的默认值
在这里插入图片描述
这是执行的参数

在这里插入图片描述
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第59张图片
加上执行权限
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第60张图片
需要在harbor里把base仓库创建出来。所有业务的底包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第61张图片
这就是base
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第62张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第63张图片
push到harbor
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第64张图片
部署maven和部署dubbo微服务的底包镜像,准备共工作做好了,就可以在jenkins里做流水线
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第65张图片

5.4 使用Jenkins进行持续构建交付dubo服务的提供者

让docker在执行的时候执行entrypoint.sh,这是一个shell脚本,docker进程在执行这个shell脚本的话,会给脚本分配一个pid,这个pid是1,docker应该是维持一个pid等于1 的进程,一定在前台运行,生命周期在running状态
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第66张图片
如果不用exec直接在shell脚本里写,java -jar,shell脚本就退出了,pid=1进程就退出了,切不到java进程,docker容器就退出了,docker容器就从running变成exited
这是shell脚本的知识,如果写了exec,就相当于exec后面的东西,代替了当前的shell脚本,从shell进程变成了pid等于1 的进程,java -jar启动的程序,dubbo程序变成了前台运行,且pid=1

不用exec,实际上相当于在entrypoint.sh弄了一个子进程,类似开了一个终端,执行了一个ps-a之类的,类似从init进程,fork出来的一个子进程。exec就是把当前的进程号给他了,到java进程手里了,这样就让写的最根本原因,为了让。docker容器生命周期,要保持在running状态而不会变成exec状态。这个是docker容器应用里比较常用的方式。nohup是后台,所以要exec

在这里插入图片描述
现在就是把base里底包做出来了,以后可以做若干底包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第67张图片
有maven软件,Dubbo服务的底包了, 现在可以配置流水线,流水线的方式去构造
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第68张图片
需要保留多少次老的构建discard old builds,保留3天和30个
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第69张图片
这个一个工程是参数化构建的,
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第70张图片
需要加10个参数,第一个参数是string parameter,参数类型是string,名字是app_name,默认值default value,description描述/
trim the string,会自动把你填的空格删除

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第71张图片
第二个参数类型是string,字符串类型的参数,名字是image_name,上面是docker提供者的一个项目,下面是一个镜像
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第72张图片
第三个参数类型仍然是字符串,git版本控制仓库的地址,比如dubbo-demo-service的项目的地址,在gitee上
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第73张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第74张图片
加不加.git其实无所谓
在这里插入图片描述
第四个也是字符串类型的参数。项目在git中央仓库所对应的,分支或者版本号,这个项目在git里有分支,master和apollo
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第75张图片
要拉到本地就checkout 版本号。这样才能去编译出来指定的哪一版本代码,要制定就找commit id,是最标准的唯一的。git上的tag其实可以篡改的,所以commit id比较好
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第76张图片
在graph上就可以看到每一次提交对应一个唯一的commit id,是不能被篡改的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第77张图片
可以checkout 分支,但是在构建的时候是分支上的最新代码,
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第78张图片
第5个参数仍然是字符串,名字add_tag,给docker镜像增加标签,要拼一个git_ver作为标签拼进来,再加上一个时间戳
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第79张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第80张图片
第6个参数,mvn_dir,在哪一个目录去执行对这个项目的编译操作,/就是在当前根目录
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第81张图片
第7个参数仍然是string parameter,编译完成项目后,产生的jar包或者war包,所在的目录
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第82张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第83张图片
第8个参数仍然是string类型,mvn_cmd执行编译所要的命令
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第84张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第85张图片
第9个参数,是choice类型,base_image,可以选择之前做的base/jre7:7u80和base/jre8:8u12,这些就是项目使用的docker底包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第86张图片
第10个参数也是choice parameter,使用的maven软件版本
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第87张图片做流水线就需要10个参数,app_name,image_name,git_repo,git_ver,add_tag,mvn_dir,target_dir,_mvn_cmd,base_image,maven

还需要些pipeline-script
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第88张图片
定义了一些stage步骤
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第89张图片
实际上执行的是shell脚本
在这里插入图片描述
把项目clone到了这里
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第90张图片
最后剪出分支
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第91张图片
build,也是cd到工作目录,执行后面的/var/jenkins_home/maven-版本
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第92张图片
也就是在这里
在这里插入图片描述
下来就是packages打包,用maven编译好项目,就需要去打包,把所有产生的jar包挪到指定文件夹里
在这里插入图片描述
下面要写dockerfile了
在这里插入图片描述
这个dockerfile是在jenkins流水线脚本自己写出来的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第93张图片
整体拼成以恶搞docker的tag,然后push到docker仓库
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第94张图片
往这里贴
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第95张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第96张图片
保留3天30份2020/05/15 k8s结合CICD持续交付及集中管理配置1_第97张图片
10个参数
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第98张图片
真正构建项目
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第99张图片
构建可以点击这两个

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第100张图片
流水线想要构架,需要填写10个参数,就会按照script进行构建
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第101张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第102张图片
harbor里可以创建app私有仓库

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第103张图片
拉取master分支的最新代码,时间戳就是19年12月1日_12点,编译地址是在项目根目录/,产生的目录是在dubbo-server/target,产生的jar包。
用的底包是base/jre8:8u12

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第104张图片
开始第一次构建,这个10个参数也是为了避免甩锅
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第105张图片
点进去

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第106张图片
点击console output
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第107张图片
第一次编译不成功很正常,因为要去国外的org拖jar包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第108张图片
常用的mvn命令,clean是把本地缓存清理掉。package 和install是对应要不要保存的问题,install就保存在本地,package是不保留在本地,-E只输出错误,-Q是静默的(就是在jenkins里根本看不到输出
在这里插入图片描述
用了流水线,就可以把200多个项目抽象成一条流水线,传不同的参数,现在dubbo服务交付提供的时候,交付dubbo服务的monitor,最后交付dubbo服务的消费者,然后dubbo服务这一套就交付到k8s里了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第109张图片
第一次构建比较慢,第二次就可以用本地缓存了,maven软件在/root/m2/repostry,很多jar包就不用去网上下载了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第110张图片
编译好后,可以推到harbor仓库里,对应的docker镜像应该是(镜像的4个组成部分,registry(harbor.od.com),repository(app),下的dubbo-demo-service:tag(master分支_191201_1200)
app仓库里会出现这么一个docker镜像

在这里插入图片描述
进入下个阶段,docker build。jenkins调用build的时候,使用的宿主机的docker引擎,
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第111张图片
push完以后就完成了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第112张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第113张图片
发现变蓝了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第114张图片
docker镜像就来了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第115张图片
点进去可以看到tag
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第116张图片
有了镜像,需要交付到k8s里,需要配置资源配置清单
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第117张图片
去做资源配置清单。只需要一个dp.yaml
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第118张图片
不需要svc。也不需要ingress
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第119张图片
注意改时间戳,打这个tag是为了方便找出问题
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第120张图片
要发到namespace里,app,把这个app namespace创建出来
在这里插入图片描述
在这里插入图片描述
紧跟着要在这个app里加入一个secret,把app名称空间和secret创建出来了
在这里插入图片描述
必须有这个,不然没法从private的仓库里拉镜像
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第121张图片
label随便打。spec里有container,对应的镜像就是harbor.od.com/app/dubbo-demo-service:master_192101_1200.,ports是暴露出来的端口,是20880

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第122张图片
env很重要,制作底包的时候,在entrypoint.sh要接收一个jar_ball环境变量,通过这个传到docker的环境变量里。

云原生的程序,配置一般通过三种方式,1.通过环境变量,2.通过启动参数,3.通过启动名称空间

在这里插入图片描述
image拉取策略有三种,always永远都去远程仓库拉,never永远不去远程仓库拉,ifnotpresent,如果没有再去远程仓库拉。
在这里插入图片描述
service account不配置,默认就是defaulte。run asuser指的是用root方式启动
在这里插入图片描述
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第123张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第124张图片
在启动应用配置清单,先去配置zk
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第125张图片
连接到zk里
在这里插入图片描述
根里只有zookeeper,没有dubbo
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第126张图片
去应用dubbo服务提供者
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第127张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第128张图片
查看是否很顺利的交付到k8s里,在app名称空间里
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第129张图片
这个pod已经起来了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第130张图片
最后会提示dubbo服务已经启动

在这里插入图片描述
这样就在k8s里完美交付了一个dubbo服务的提供者,用jenkins去持续构建,把dubbo服务的提供者列出来,通过资源配置清单,交付到k8s里,去zk列出来list,dubbo服务的接口
在这里插入图片描述

5.5 借助BlueOcean插件回顾Jenkins流水线构建原理

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第131张图片
交付了jenkins到k8s集群,安装blue ocean插件
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第132张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第133张图片
这几步都已经有了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第134张图片
**第一步pull代码,克隆代码到jenkins_home/workspace/dubbo_demo_service/1
**
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第135张图片
就是把代码克隆到这里

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第136张图片
然后做一个checkout,指定的代码
在这里插入图片描述
第二步编译代码
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第137张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第138张图片
第三步打包
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第139张图片
第四步做docker镜像
write file to workspace就是写dockerfile

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第140张图片
dockerfile位置
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第141张图片
这个dockerfile是由jenkins自己pipeline cript写出来的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第142张图片
就是form一个底包,然后把文件拷贝下

在这里插入图片描述
这里没有dockerfile,做法是让jenkins自己写
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第143张图片
docker build之后就是docker push。放到harbor里了2020/05/15 k8s结合CICD持续交付及集中管理配置1_第144张图片
jenkins的流水线就做了4件事情,如果要用python流水线就需要在最前面判断是否有docker镜像,因为同时有人提交一样的tag就报错了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第145张图片

5.6 交付dubbo-monitor到K8S集群

现在镜像构建出来了已经到harbor里了,发到k8s集群里了

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第146张图片
发到k8s集群里,就需要资源配置清单,dubbo服务的提供者只需要一个deveploment类型的pod控制器
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第147张图片
提供者最后可以在日志里看到dubbo服务端已经启动
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第148张图片
交付了以后,zk有dubbo节点
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第149张图片
需要一个zk的页面,这个页面就叫做监控者,方便查看哪些已经注册,哪些没注册
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第150张图片
monitor就是个取数据用来展示,dubbo里的monitor有两个软件做的比较好dubbo-admin,dubbo-monitor
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第151张图片
交付dubbo-monitor工具

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第152张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第153张图片
下载一下
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第154张图片
直接get到运维主机
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第155张图片
直接解压
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第156张图片
unzip到当前目录

在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第157张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第158张图片
先去修改dubbo_origin.properties
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第159张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第160张图片
rpc接口是20880
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第161张图片
保存退出后,可以发现dockerfile都准备好了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第162张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第163张图片
光用它的dockerfile还不行,还要给start.sh做一下改变
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第164张图片
不改变,提供的dockerfile就起不来
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第165张图片
对jvm进行了定义,这里用了2G,太丧心病狂了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第166张图片
按比例缩小一下
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第167张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第168张图片
最重要的是在这里。这个就是sh,相当于entrypoint.sh,写了nohup就不能保持docker保持running状态
在这里插入图片描述
调整这句话,要在前台跑,exec下面所有内容删除
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第169张图片
其实这条sed命令就可以搞定
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第170张图片
为了规范一点,复制到/data/dockerfile下
在这里插入图片描述

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第171张图片
把simple这个目录拷贝到/dubbo里
在这里插入图片描述

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第172张图片
执行一个main方法
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第173张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第174张图片

现在去build docker镜像
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第175张图片
在这里插入图片描述
push到harbor仓库里,这个docker build和push是一对操作
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第176张图片
这就是做好的docker-monitor的docker镜像
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第177张图片
要用这个镜像,把docker发到k8s里,需要资源配置清单
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第178张图片
做好一个镜像,准备资源配置清单,应用到k8s里
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第179张图片
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第180张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第181张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第182张图片
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第183张图片
在这里插入图片描述
targetport是在docker里跑的端口,port是clusterip上跑的端口

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第184张图片
问题是在ingress里
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第185张图片
这两个port需要对上,port是service在clusterip上跑的端口,要和ingress上的port对上

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第186张图片
在这里插入图片描述
在这里插入图片描述
先到浏览器看看

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第187张图片
现在去交付dp
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
infra里就起来了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第188张图片
看一下日志,重定向到file里,可能看不出来

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第189张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第190张图片
ingress已经创建出来了,要访问页面,,就需要解析dns,不能随便解析,需要看ingress用的是什么域名
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第191张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第192张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第193张图片
在这里插入图片描述
在这里插入图片描述
这样就出来了,解析的原理,指到vip,通过7层反向代理,给了ingress控制器,由ingress再去找service,service帮你找pod
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第194张图片
链接的哪个zk,容器跑在了7.21这个主机上

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第195张图片
dubbo-demo-service就是dubbo服务的提供者,provider2个

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第196张图片
两个rpc接口
在这里插入图片描述
现在就把dubbo服务的monitor交付到k8s集群了

5.7 交付dubbo服务的消费者集群到K8S

把dubbo服务的提供者和monitor都交付给k8s里了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第197张图片
下面交付dubbo服务的消费者,需要借助Jenkins的持续集成
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第198张图片
这一条流水线,可以构建dubbo服务的提供者又可以用来构建dubbo服务的消费者
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第199张图片

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第200张图片
构建dubbo服务的消费者consumer,消费者是要用到ssh公钥,因为要去和git链接

public是consumer,private是web

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第201张图片

如果要去拖dubbo-demo-web的项目的时候,需要用ssh通道
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第202张图片
暂且用master分支,-e -q输出的就少
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第203张图片
开始构建了

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第204张图片
**先 git clone,然后checkout **
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第205张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第206张图片
repository是本地缓存。第二次编译,有这些jar包就快了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第207张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第208张图片
到blue ocean看第二次构建
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第209张图片
现在要交付消费者,就要准备资源配置清单。套路就是把项目构建成,打个包扔到harbor仓库,然后准备资源配置清单。
需要三个资源配置清单

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第210张图片
改一下时间

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第211张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第212张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第213张图片
env是,jar_ball是dubbo-client.jar
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第214张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第215张图片
第二步,创建svc.yaml
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第216张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第217张图片
docker容器了是监听的8080,映射的clusterip也是8080
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第218张图片
docker-monitor,是在172.7.21.8
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第219张图片
docker-monitor,是监听在clusterip192.168.117.64 8080端口上。jenkins是80端口监听在了192.168.88.235上
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第220张图片
k8s最核心的资源,三种:pod控制器,svc,ingress,往k8s交付都是这种套路
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第221张图片
用的域名是demo.od.com
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第222张图片
解析域名,前滚serial
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第223张图片
在这里插入图片描述
在这里插入图片描述
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第224张图片
现在还要依次应用资源配置清单
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第225张图片
起来了

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第226张图片
消费者启动
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第227张图片
docker-monitor刷新就有consumer了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第228张图片
这里有consumer的这样一个接口
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第229张图片
去zk注册了订阅一个方法
在这里插入图片描述
这就是dubbo-demo消费者端

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第230张图片
这个hello就是从请求的消费者端,里面去调用helloService.hello,就好像在调用本地的方法一样
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第231张图片
提供者才真正实现hello方法
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第232张图片
消费者在调用hello方法的时候就好像在调用本地方法

pod控制器,有dubbo服务的消费者和提供者,可以分别扩容
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第233张图片
加入高并发来了,可以直接扩容3份
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第234张图片
pod里dubbo service就有3个了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第235张图片
dubbo服务的service和consumer,就是典型的没有状态的服务,可以随便扩容
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第236张图片

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第237张图片
前端根本毫无感觉,dubbo内部就会做负载均衡
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第238张图片
这里的负载均衡是k8s做的,consumer可以扩容2份
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第239张图片
traefik就对应了两个dubbo-demo-consumer,相当于traefik帮你找到了两个后端真实的server,对应podip,实际上抗前端的流量,帮你分成2个,再帮你调用后端service的时候,就变成3个,这个负载均衡机制是dubbo做的
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第240张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第241张图片
dubbo可以在内网替代负载均衡,软负载均衡及容错机制,实际上是消费者靠dubbo软负载机制,可以前后端分别扩容
在这里插入图片描述
点点鼠标就完成了资源扩容和回收
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第242张图片

5.8 实战dubbo集群的日常维护

停止可以优雅地停止,可以都执行完了退出,再让pod停止
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第243张图片
如果把service缩容成4个
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第244张图片不会立刻变成1
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第245张图片
pod生命周期有prestop,在停止之前,还可以做一些事情,写shell脚本,相当于一个钩子,可以优雅停止自己,最后在zk里把自己删除

k8s作为容器编排框架,都pod定义的还是比较完善的生命周期,还有init

可以修改consumer,迭代这个功能
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第246张图片
直接commit
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第247张图片
commit以后会产生一个commitid
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第248张图片
拷贝这个commitid,拷贝8位即可
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第249张图片
再用jenkins构建
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第250张图片
这是新构建的镜像

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第251张图片
现在发版有两种方法,修改资源配置清单,要么在dashboard上改
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第252张图片
修改镜像并且update
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第253张图片
修改成功
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第254张图片
如果要回滚
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第255张图片
扩容到3份
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第256张图片
回滚只需要看pod控制器
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第257张图片
镜像tag一贴

2020/05/15 k8s结合CICD持续交付及集中管理配置1_第258张图片
现在就回滚完了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第259张图片
pod控制器就是让pod无限接近预期
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第260张图片
这就回滚完了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第261张图片
要实现的是这个模型
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第262张图片
从harbor到k8s-yaml自动化生成还没实现
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第263张图片
jenkins到git是持续构建ci
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第264张图片
ops服务器到yaml到部署到k8s里就是持续部署CD
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第265张图片
现在缩容
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第266张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第267张图片
如果改成0
在这里插入图片描述
service就没了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第268张图片
现在抛出异常就找不到hello方法了,dubbo集群里没有提供者提供方法了
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第269张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第270张图片
恢复1个
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第271张图片
2020/05/15 k8s结合CICD持续交付及集中管理配置1_第272张图片

你可能感兴趣的:(2020/05/15 k8s结合CICD持续交付及集中管理配置1)