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