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

最新推荐文章于 2024-05-15 16:38:03 发布

48N6E

最新推荐文章于 2024-05-15 16:38:03 发布

阅读量529

点赞数

本文链接：https://blog.csdn.net/qq_42227818/article/details/106137306

版权

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集群，还需要改源码，重新编译

在这里插入图片描述

Dubbo微服务的架构，registry注册中心（zookeeper），有提供者（部署到k8s里，注册到注册中心）和消费者（订阅注册中心的方法，rpc），消费者在使用的时候，就是像在本地调用一样，还有moniter去观察组件消费者和提供者工作是否正常

在这里插入图片描述

交付zookeeper和jenkins，jenkins是作为一个持续集成的组件，帮助我们把源代码从版本控制中心git，也可以用svn，通过配置和编译，把源代码通过编译变成了一个可执行的二进制码，
jenkins主要作用就是编译好代码，打成docker镜像，并提交到私有仓库里，这就是交付jenkins主要做的三件事，拉代码，编译，放到仓库里
在这里插入图片描述
主要是让jenkins和harbor仓库进行通信，推送镜像

让jenkins使用docker引擎，在jenkins里安装客户端

jenkins的docker客户端是和宿主机服务端通过socket进行通信

第一需要有docker镜像，第二把镜像扔到harbor仓库，k8s本身要从私有仓库里拉镜像，第三是要准备资源配置清单，根据服务特点给相应的资源配置清单，必须要包含的是一个pod控制器，这个pod控制器是有daemonset，可能是deployment也可能是其他的，必然包含pod控制器，和svc和ingress。
准备好资源配置清单，就应用到了k8s集群里
在这里插入图片描述
需要安装这个blue ocean

5.2 二进制安装maven

只有fully up and running才证明jenkins完全起来了
在这里插入图片描述
jenkins的容器还是比较耗费资源，普罗米修斯随便就吃20G内存

验证jenkins可用，需要做一些事情

用web shell的方式到jenkins容器里

是否以root方式启动，时区是否是东8区，是否连接到宿主机的docker引擎
在这里插入图片描述
跟21主机上所有容器列出的一模一样

还要去验证是否能登陆harbor仓库

这个是dockerfile里就指定的

用git用户去连接 test连接 -T指的是test测试连接，不是真正的连接

下面要安装部署maven，是用来编译java程序，maven是阿帕奇基金会开源的
在这里插入图片描述
一般jdk1.7，用maven 3

选择编译好的，选择清华大学的源

这些都是已经归档的

binaries二进制包

jdk版本指的是jenkins里的jdk版本

看一下版本

看一下版本
先把目录创建出来

在这里插入图片描述

把那一层取消

要对maven做初始化配置，源设置成国内的，这样拉jar包就直接在阿里云里拉了

可以在jenkins _home里可以安装你想要的工具

docker镜像就是挂载了宿主机上

5.3 dubbo微服务底包镜像制作

build jenkins，实际要get docker，要用到国外的源，所以build的时候要失败很多次，实在不行就直接用软件包，这就是一个docker镜像
在这里插入图片描述
这是已经把get docker整合进去了

这样存到harbor里，再去build就快了

load到docker引擎里，一层层加载，aufs

找到这个images，就需要打一个标签，push到仓库

修改dockerfile

到infra仓库里
就是build不过去，只能采用这种方法
在这里插入图片描述
只需要把底包加载进来，然后，12，3，4，5，6，

在这里插入图片描述
maven3也可以指定不同的jdk来编译

下载jdk

解压到当前目录

这个jdk就进来了

如果maven不能用1.8jdk，需要到目录里一个脚本

在这里插入图片描述
java_home可以定义成当前jdk1.7，也就是执行maven命令的时候，用的是1.7，而没有用jenkins容器里的1.8，可以去手动的用maven指定jdk，只要去编辑maven脚本即可
**加粗样式**

这只是演示，然后把安装的jdk删除
在这里插入图片描述
下一步交付Dubbo微服务提供者和消费者，需要准备一个底包，找到一个合适运行时环境底包

debian系列的底包

把镜像pull下来

也可以run 这个sh的时候指定源是阿里云

有一个jre7 ，有一个jre8，可以直接用
在这里插入图片描述

下载下来的镜像应该打个tag，放到harbor镜像里

在这里插入图片描述

下载底包，调整时区，add confg.yml监控的，jmx_javaagent是收集jvm的信息，这个相当于采集jvm的jar包，一个采集jvm的客户端

下载下来

一般架构师就是通过监控jvm来调优。首先vi config.yml

这里相当于指定工作目录是opt/project.dir

在这里插入图片描述
docker默认运行的启动脚本

entrypoint.sh 定义了三个变量

这个变量是当前docker运行的环境变量有一个JAR_BALL的变量，赋值到shell脚本里，k8s的yaml配置清单里，可以传一个变量。这就是云原生的思想，docker不是信息孤岛，可以通过k8s配置清单，环境变量的方式来给容器做一些初始化的操作
、在这里插入图片描述
这是java的一些启动参数

这是docker的ip，在k8s里叫pod IP

这是12346是m_port的默认值

这是执行的参数

在这里插入图片描述

加上执行权限

需要在harbor里把base仓库创建出来。所有业务的底包

这就是base

push到harbor

部署maven和部署dubbo微服务的底包镜像，准备共工作做好了，就可以在jenkins里做流水线

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

让docker在执行的时候执行entrypoint.sh，这是一个shell脚本，docker进程在执行这个shell脚本的话，会给脚本分配一个pid，这个pid是1，docker应该是维持一个pid等于1 的进程，一定在前台运行，生命周期在running状态
在这里插入图片描述
如果不用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里底包做出来了，以后可以做若干底包

有maven软件，Dubbo服务的底包了，现在可以配置流水线，流水线的方式去构造

需要保留多少次老的构建discard old builds，保留3天和30个

这个一个工程是参数化构建的，
在这里插入图片描述
需要加10个参数，第一个参数是string parameter，参数类型是string，名字是app_name，默认值default value,description描述/
trim the string，会自动把你填的空格删除

在这里插入图片描述
第二个参数类型是string，字符串类型的参数，名字是image_name,上面是docker提供者的一个项目，下面是一个镜像

第三个参数类型仍然是字符串，git版本控制仓库的地址，比如dubbo-demo-service的项目的地址，在gitee上
在这里插入图片描述

加不加.git其实无所谓

第四个也是字符串类型的参数。项目在git中央仓库所对应的，分支或者版本号，这个项目在git里有分支，master和apollo

要拉到本地就checkout 版本号。这样才能去编译出来指定的哪一版本代码，要制定就找commit id，是最标准的唯一的。git上的tag其实可以篡改的，所以commit id比较好
在这里插入图片描述
在graph上就可以看到每一次提交对应一个唯一的commit id，是不能被篡改的

可以checkout 分支，但是在构建的时候是分支上的最新代码，

第5个参数仍然是字符串，名字add_tag，给docker镜像增加标签，要拼一个git_ver作为标签拼进来，再加上一个时间戳
在这里插入图片描述

第6个参数，mvn_dir，在哪一个目录去执行对这个项目的编译操作，/就是在当前根目录

第7个参数仍然是string parameter，编译完成项目后，产生的jar包或者war包，所在的目录

第8个参数仍然是string类型，mvn_cmd执行编译所要的命令
在这里插入图片描述

第9个参数，是choice类型，base_image，可以选择之前做的base/jre7：7u80和base/jre8:8u12，这些就是项目使用的docker底包

第10个参数也是choice parameter，使用的maven软件版本
做流水线就需要10个参数，app_name,image_name,git_repo,git_ver,add_tag,mvn_dir,target_dir,_mvn_cmd,base_image,maven

还需要些pipeline-script
在这里插入图片描述
定义了一些stage步骤

实际上执行的是shell脚本

把项目clone到了这里

最后剪出分支

build，也是cd到工作目录，执行后面的/var/jenkins_home/maven-版本

也就是在这里

下来就是packages打包，用maven编译好项目，就需要去打包，把所有产生的jar包挪到指定文件夹里
在这里插入图片描述
下面要写dockerfile了

这个dockerfile是在jenkins流水线脚本自己写出来的

整体拼成以恶搞docker的tag，然后push到docker仓库

往这里贴

保留3天30份
10个参数

真正构建项目

构建可以点击这两个

在这里插入图片描述
流水线想要构架，需要填写10个参数，就会按照script进行构建

harbor里可以创建app私有仓库

在这里插入图片描述
拉取master分支的最新代码，时间戳就是19年12月1日_12点，编译地址是在项目根目录/，产生的目录是在dubbo-server/target,产生的jar包。
用的底包是base/jre8:8u12

开始第一次构建，这个10个参数也是为了避免甩锅
在这里插入图片描述
点进去

在这里插入图片描述
点击console output

第一次编译不成功很正常，因为要去国外的org拖jar包

常用的mvn命令，clean是把本地缓存清理掉。package 和install是对应要不要保存的问题，install就保存在本地，package是不保留在本地，-E只输出错误，-Q是静默的（就是在jenkins里根本看不到输出
在这里插入图片描述
用了流水线，就可以把200多个项目抽象成一条流水线，传不同的参数，现在dubbo服务交付提供的时候，交付dubbo服务的monitor，最后交付dubbo服务的消费者，然后dubbo服务这一套就交付到k8s里了

第一次构建比较慢，第二次就可以用本地缓存了，maven软件在/root/m2/repostry，很多jar包就不用去网上下载了
在这里插入图片描述
编译好后，可以推到harbor仓库里，对应的docker镜像应该是（镜像的4个组成部分，registry(harbor.od.com)，repository(app),下的dubbo-demo-service：tag（master分支_191201_1200）
app仓库里会出现这么一个docker镜像

进入下个阶段，docker build。jenkins调用build的时候，使用的宿主机的docker引擎，
在这里插入图片描述
push完以后就完成了

发现变蓝了

docker镜像就来了

点进去可以看到tag

有了镜像，需要交付到k8s里，需要配置资源配置清单

去做资源配置清单。只需要一个dp.yaml

不需要svc。也不需要ingress
在这里插入图片描述
注意改时间戳，打这个tag是为了方便找出问题

要发到namespace里，app，把这个app namespace创建出来

紧跟着要在这个app里加入一个secret，把app名称空间和secret创建出来了

必须有这个，不然没法从private的仓库里拉镜像
、在这里插入图片描述
label随便打。spec里有container，对应的镜像就是harbor.od.com/app/dubbo-demo-service:master_192101_1200.,ports是暴露出来的端口，是20880

在这里插入图片描述
env很重要，制作底包的时候，在entrypoint.sh要接收一个jar_ball环境变量，通过这个传到docker的环境变量里。

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

在这里插入图片描述
image拉取策略有三种，always永远都去远程仓库拉，never永远不去远程仓库拉，ifnotpresent，如果没有再去远程仓库拉。

service account不配置，默认就是defaulte。run asuser指的是用root方式启动

在启动应用配置清单，先去配置zk
在这里插入图片描述
连接到zk里

根里只有zookeeper，没有dubbo

去应用dubbo服务提供者

查看是否很顺利的交付到k8s里，在app名称空间里

这个pod已经起来了

最后会提示dubbo服务已经启动

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

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

在这里插入图片描述
交付了jenkins到k8s集群，安装blue ocean插件

这几步都已经有了

**第一步pull代码，克隆代码到jenkins_home/workspace/dubbo_demo_service/1
**

就是把代码克隆到这里

在这里插入图片描述
然后做一个checkout，指定的代码

第二步编译代码

第三步打包

第四步做docker镜像
write file to workspace就是写dockerfile

dockerfile位置

这个dockerfile是由jenkins自己pipeline cript写出来的

就是form一个底包，然后把文件拷贝下

在这里插入图片描述
这里没有dockerfile，做法是让jenkins自己写

docker build之后就是docker push。放到harbor里了
jenkins的流水线就做了4件事情，如果要用python流水线就需要在最前面判断是否有docker镜像，因为同时有人提交一样的tag就报错了
在这里插入图片描述

5.6 交付dubbo-monitor到K8S集群

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

在这里插入图片描述
发到k8s集群里，就需要资源配置清单，dubbo服务的提供者只需要一个deveploment类型的pod控制器

提供者最后可以在日志里看到dubbo服务端已经启动

交付了以后，zk有dubbo节点

需要一个zk的页面，这个页面就叫做监控者，方便查看哪些已经注册，哪些没注册
在这里插入图片描述
monitor就是个取数据用来展示，dubbo里的monitor有两个软件做的比较好dubbo-admin，dubbo-monitor

交付dubbo-monitor工具

在这里插入图片描述

下载一下

直接get到运维主机

直接解压

unzip到当前目录

在这里插入图片描述

先去修改dubbo_origin.properties

rpc接口是20880

保存退出后，可以发现dockerfile都准备好了

光用它的dockerfile还不行，还要给start.sh做一下改变

不改变，提供的dockerfile就起不来

对jvm进行了定义，这里用了2G，太丧心病狂了
在这里插入图片描述
按比例缩小一下

最重要的是在这里。这个就是sh，相当于entrypoint.sh，写了nohup就不能保持docker保持running状态

调整这句话，要在前台跑，exec下面所有内容删除

其实这条sed命令就可以搞定
在这里插入图片描述

为了规范一点，复制到/data/dockerfile下

在这里插入图片描述
把simple这个目录拷贝到/dubbo里

在这里插入图片描述
执行一个main方法

现在去build docker镜像
在这里插入图片描述

push到harbor仓库里，这个docker build和push是一对操作

这就是做好的docker-monitor的docker镜像

要用这个镜像，把docker发到k8s里，需要资源配置清单

做好一个镜像，准备资源配置清单，应用到k8s里
在这里插入图片描述

targetport是在docker里跑的端口，port是clusterip上跑的端口

在这里插入图片描述
问题是在ingress里

这两个port需要对上，port是service在clusterip上跑的端口，要和ingress上的port对上

在这里插入图片描述

先到浏览器看看

在这里插入图片描述
现在去交付dp

infra里就起来了

看一下日志，重定向到file里，可能看不出来

在这里插入图片描述

ingress已经创建出来了，要访问页面，，就需要解析dns，不能随便解析，需要看ingress用的是什么域名

这样就出来了，解析的原理，指到vip，通过7层反向代理，给了ingress控制器，由ingress再去找service，service帮你找pod
在这里插入图片描述
链接的哪个zk，容器跑在了7.21这个主机上

在这里插入图片描述
dubbo-demo-service就是dubbo服务的提供者，provider2个

在这里插入图片描述
两个rpc接口

现在就把dubbo服务的monitor交付到k8s集群了

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

把dubbo服务的提供者和monitor都交付给k8s里了
在这里插入图片描述
下面交付dubbo服务的消费者，需要借助Jenkins的持续集成

这一条流水线，可以构建dubbo服务的提供者又可以用来构建dubbo服务的消费者

在这里插入图片描述
构建dubbo服务的消费者consumer，消费者是要用到ssh公钥，因为要去和git链接

public是consumer，private是web

在这里插入图片描述

如果要去拖dubbo-demo-web的项目的时候，需要用ssh通道
在这里插入图片描述
暂且用master分支，-e -q输出的就少

开始构建了

在这里插入图片描述
**先 git clone，然后checkout **

repository是本地缓存。第二次编译，有这些jar包就快了

到blue ocean看第二次构建

现在要交付消费者，就要准备资源配置清单。套路就是把项目构建成，打个包扔到harbor仓库，然后准备资源配置清单。
需要三个资源配置清单
在这里插入图片描述
改一下时间

在这里插入图片描述

env是，jar_ball是dubbo-client.jar

第二步，创建svc.yaml

docker容器了是监听的8080，映射的clusterip也是8080

docker-monitor，是在172.7.21.8

docker-monitor,是监听在clusterip192.168.117.64 8080端口上。jenkins是80端口监听在了192.168.88.235上
在这里插入图片描述

k8s最核心的资源，三种：pod控制器，svc，ingress，往k8s交付都是这种套路

用的域名是demo.od.com

解析域名，前滚serial

现在还要依次应用资源配置清单

起来了

在这里插入图片描述
消费者启动

docker-monitor刷新就有consumer了

这里有consumer的这样一个接口

去zk注册了订阅一个方法

这就是dubbo-demo消费者端

在这里插入图片描述
这个hello就是从请求的消费者端，里面去调用helloService.hello，就好像在调用本地的方法一样

提供者才真正实现hello方法

消费者在调用hello方法的时候就好像在调用本地方法

pod控制器，有dubbo服务的消费者和提供者，可以分别扩容
在这里插入图片描述
加入高并发来了，可以直接扩容3份

pod里dubbo service就有3个了

dubbo服务的service和consumer，就是典型的没有状态的服务，可以随便扩容

在这里插入图片描述
前端根本毫无感觉，dubbo内部就会做负载均衡
、
这里的负载均衡是k8s做的，consumer可以扩容2份

traefik就对应了两个dubbo-demo-consumer，相当于traefik帮你找到了两个后端真实的server，对应podip，实际上抗前端的流量，帮你分成2个，再帮你调用后端service的时候，就变成3个，这个负载均衡机制是dubbo做的
在这里插入图片描述

dubbo可以在内网替代负载均衡，软负载均衡及容错机制，实际上是消费者靠dubbo软负载机制，可以前后端分别扩容

点点鼠标就完成了资源扩容和回收

5.8 实战dubbo集群的日常维护

停止可以优雅地停止，可以都执行完了退出，再让pod停止
**加粗样式**
如果把service缩容成4个
在这里插入图片描述 不会立刻变成1

pod生命周期有prestop，在停止之前，还可以做一些事情，写shell脚本，相当于一个钩子，可以优雅停止自己，最后在zk里把自己删除

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

可以修改consumer，迭代这个功能
在这里插入图片描述
直接commit

commit以后会产生一个commitid

拷贝这个commitid，拷贝8位即可

再用jenkins构建

这是新构建的镜像

在这里插入图片描述
现在发版有两种方法，修改资源配置清单，要么在dashboard上改

修改镜像并且update

修改成功

如果要回滚

扩容到3份

回滚只需要看pod控制器

镜像tag一贴

在这里插入图片描述
现在就回滚完了

pod控制器就是让pod无限接近预期

这就回滚完了

要实现的是这个模型

从harbor到k8s-yaml自动化生成还没实现

jenkins到git是持续构建ci

ops服务器到yaml到部署到k8s里就是持续部署CD
在这里插入图片描述
现在缩容

如果改成0

service就没了

现在抛出异常就找不到hello方法了，dubbo集群里没有提供者提供方法了

恢复1个