作者主页(文火冰糖的硅基工坊):文火冰糖(王文兵)的博客_文火冰糖的硅基工坊_CSDN博客
本文网址:https://blog.csdn.net/HiWangWenBing/article/details/123025569
目录
前置条件
第一步:创建DevOps工程
第二步:创建流水线框架
第1步骤:选择框架
第2步:选择基础镜像代理
第三步:持续集成
第1步:拉取代码(pull)
第2步骤:编译代码与打包
第四步:持续发布
第1步:构建docker镜像
第2步骤:持续发布docker镜像 - 推送到阿朗云镜像仓库
第五步:持续部署
第1步:部署到dev开发环境
第2步:部署到生产环境
第六步:邮寄通知
第七步:代码仓库的Webhook自动触发Jenkis的pipeline
总结:
(1)流程的自动化
(2)Kubesphere对Jenkis的深度整合体现
(3)支持的4种Docker
(4)登录第三方服务器的凭证
(5)第三方服务的类型
(6)操作对象的内置方法 -- 配置文件
感悟:Kubesphere + pipeline的目标
(1)微服务所依赖第三方中间件微服务已经通过手工的方式进行部署。
(2)第三方中间件库,不需要反复构建,因此他们的部署被安排在此流程之外
(1)以管理员身份登录到Kubesphere的后台管理系统,先创建一个DevOps项目/工程
(2)邀请其他人参与到该工程中
(3)项目成员登录到Kubesphere的后台管理系统,创建pipeline
与原生的jenkis需要手工编写pipelineflie不同,Kubesphere是通过图形化的方式创建pipeline,并自动生成相关的代码。
Kubesphere支持三种流水线模板:
Kubesphere自动创建CI/CD的流水线,自动生成相关的代码。
然后基于该模板,就可以进行裁剪和修整(编译流水线),这一种方式大大节省了初创一个pipeline的过程,提高了效率。
Kubesphere是微服务集群管理系统,其pipeline功能的各个步骤的执行,各个pipeline,也是基于集群的,基于微服务的,?不同的pipleline或不同的构建步骤?,最终生成的是一个微服务镜像,Kubesphere会启动这些微服务进行执行pipleline的工作。
备注:代理/容器是不是针对pipeline的,而是针对某个stage步骤的。
这样的设计,带了一个好处:pipeline的每个步骤,可以动态的进行创建和删除,同时这些步骤,可以通过集群的方式分布在不同的node上执行,提升了整体的执行效率。
这里有4种类型的代理:
DevOps 工程 - Jenkins Agent 说明 - 《KubeSphere v2.0 使用手册》 - 书栈网 · BookStack
(1)base:该基础镜像中,包含Linux、github、docker、K8S常见的工具。
(2)go:该基础镜像中,除了包含Linux、github、docker、K8S常见的工具,还包含了go语言开发常用的工具。
(3)maven:该基础镜像中,除了包含Linux、github、docker、K8S常见的工具,还包含了java后台程序开发常见的开发、发布工具,特别是maven打包工具。
(4)nodejs: 该基础镜像中,除了包含Linux、github、docker、K8S常见的工具,还包含了nodejs前台程序开发常见的开发、发布工具。
pipleline的每一个步骤的最终执行,都需要各种软件工具,这些工具都会包装在pipeline生成的容器中。
正是因为这4种类型的容器,支撑了Kubesphere所有的pipeline的功能。
所以,Kubesphere不仅仅是简单的利用了jenkis,而是对jenkis进行了深度整合。
几个关键概念:
pipeline:流水线,每个devops项目可以有多个pipeline
stage:阶段,隶属于pipeline,包括cline code, unit test,build&push......
容器:为不同的step指定和创建不同的微服务容器。
step:隶属于stage,每个stage可以包含多个步骤。
条件:条件是针对某个step的,但条件满足的时候就执行,条件不满足的时候就不执行。
action:每个步骤执行的动作,通常是执行或调用某个脚本
(1)指定容器类型
(2)设定github的代码路径
(2)如果是私有代码,还需要配置凭证(用户名、密码、认证信息)
(3)拉去代码后的检查
添加linux的命令
# 检查代码存放位置:
pwd
# 显示获取的代码目录
ls
在build代码时,会下载mvn工具的所有依赖文件和工具,默认从mvn的官方仓库中下下载,速度较慢,如果通过管理员账号,进入Kubesphere后台管理系统,重新设置依赖下载镜像的位置转到阿里云平台,而不是官方平台。
备注:
上述修改后,会缩短编译打包的时间,提升效率。
Kubesphere增加了缓存机制,不是每次都需要远程下载依赖文件
在集群中一个项目的编译时间非常端,可能只需要几十秒就可以完成!!!
(1)创建步骤
自动构建docker前提是每个制品内部都已经编写好了相应的dockerfile, 这在微服务在编译前,就已经写好了,并且与源代码一起发布的。
(2)添加一个step,确认当前目录中有生成docker镜像有需要的输入文件
(3)添加一个step,更加dockerfile执行构建docker镜像
(4)为剩余的每个微服务创建并发step,并发的构建各自的镜像
备注:所谓并发构建,并不是串行的,而是并行的,且分布在云端的分布式计算单元上,可以实现负载均衡。
这种方式,极大的提升了效率。
(1)添加步骤:显示当前镜像信息
(2)添加步骤:创建连接阿里云的凭证
(3)连接到阿里云
(4)修改tag
(5)push镜像
(6)建立并行推送,推送所有镜像
(7)登录到阿里云平台检查推送结果
(1)前提
每个微服务都有一个deploy目录,里面有一个deploy.yml文件,设定了如何部署该微服务。
(2)通过admin账号,为项目访问阿里云仓库创建相应的凭证
(3)在deploy.yml中指定镜像在阿里云的位置、访问阿里云的凭证信息。
(4)在deploy.yml中指定如何部署
(5)创建一个微服务部署的step
(6)获取部署微服务的凭证(root用户的)
(7)指定deploy.yml的位置
(8)应用配置文件(平台根据前面的配置,自动构建命令,不需要手工输入)
$cubectl apply -f ....
(9)添加并行部署步骤: 修改jenkisfile文件或UI操作
(10)通过Kubesphere后台管理程序查看部署的微服务
(11)修改nacos数据库,确保每个服务的MySQL和Reids的地址信息是正确的。
(12)为MySQL数据库导入微服务所需要的数据库
(13)通过Kubesphere后台管理程序查看微服务的部署情况
这个环节经常会看到容器不能正常启动,容器出错启动出错,出错的原因比较复杂多样
因此,需要根据实际情况,进行排查和排查故障。
(1)人工审核
只有有权限的账号,确认后,才允许进一步的部署。
(2)部署应用
同步骤1.
Kubesphere自身并没有发送邮寄的功能,它还需要触发邮寄服务器来发送邮件。
(1)设定邮寄服务器和发送邮寄的账号信息
在这里可以设定发送邮寄的服务器、账号、密码、接受邮件地址等信息。
Kubesphere会利用这些信息,登录到邮件服务器,给指定邮箱发送邮寄。
(2)添加发送邮寄的嵌套步骤
(3)设置邮寄发送的内容
(1)创建流水线时自动创建其WebHook
备注:必须先指定代码仓库,才会自动生成代码仓库对应的Webhook。
(2)在代码长仓库中添加Webhook
(3)设置webhook的触发条件
(4)触发消息
Kubesphere + Jenkis解决了整个上云流程的自动化,从程序提交代码开始,到镜像直接部署到云平台:docker + K8S + Kubesphere。
整个流程是通过图形化方式展示的,但通过配置文件的方式保存信息的。
pipleline配置文件为:jenkisfile
在这个流程中,需要登录到外部的服务器,下载镜像、上传镜像,发送邮寄等,这就涉及到如何登录远程服务器问题,Kubesphere采用的是凭证的方法,记录登录远程服务无所需要的信息:
Kubesphere只解决流程的自动化,但并不能直接某个流程自身的操作方法问题,这就需要操作流程自身自我配置的能力,主要通过环境变量和配置文件两种方法实现的。
相应的配置文件有:
自此,Kubesphere + pipeline自动上云部署的过程就结束了。
用户只需要把自己的精力放在微服务本身的业务逻辑上,把机械性的流程、日常的微服务运维、治理都交给云平台完成!!!
一个全自动的、软件生产线就这样形成了,它源源不断的生产出新的产品。
这无论对大公司还是创业公司,都是一个福音,极大的提升了软件生成的效率。
作者主页(文火冰糖的硅基工坊):文火冰糖(王文兵)的博客_文火冰糖的硅基工坊_CSDN博客
本文网址:https://blog.csdn.net/HiWangWenBing/article/details/123025569