[云原生专题-63]：Kubesphere云治理-DevOps-微服务自动上云部署的pipeline全部流程和详细步骤

Posted 2022-02-25 文火冰糖的硅基工坊

作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_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）第三方中间件库，不需要反复构建，因此他们的部署被安排在此流程之外

第一步：创建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