前一段时间倒腾k8s的时候,写了一系列的博客,有很多人不理解那样做的意义是什么,为什么要那样做,这篇文章就尝试解释一下,在实际环境中,是如何让集群为我们工作的.
因为只研究了一个月左右的时间,认识难免有偏颇之处,到时还望指出.
首先,上一张架构图:
- Dockerfile:用来制作镜像.Dockerfile的设计思想就是,使用一些标准的原语来描述我们所需要构建的Docker镜像,并且按顺序来进行处理.所以对于Dockerfile我就不多说了,里面内容挺简单而且挺容易理解的.
- yaml文件:用来部署服务.
- Jenkins构建完成之后,还需要执行一个脚本,在这里先提出来,在后面还会进行相关讲解
| 详细说明 |
接下来就详细说一说架构图:
1,代码和相关war包就不说了,对于项目来说,这是必不可少的内容.
2,Dockerfile文件中,需要写相关内容.以我在实际环境中的运用为例:
FROM reg.zll.com/library/nginx:latest
COPY dist /usr/local/dist
在上面我说过了,Dockerfile的设计思想就是,使用一些标准的原语来描述我们所需要构建的Docker镜像,并且按顺序来进行处理,所以我们来看Dockerfile文件中的内容很容易理解:首先需要从Harbor镜像仓库(reg.zll.com就是我搭建的Harbor镜像仓库)中,拉取我们需要的镜像,然后将Jenkins构建之后的dist拷贝到指定目录下.
3, yaml文件负责在k8s上创建相应的pod，在这里根据项目的需要,建立了2个，一个是deployment（负责运行这个镜像），一个是service（负责服务发现）
关于yaml文件,我写过一篇博客,对于在Kubernetes中的应用来说,应该是够用了,感兴趣可以参考:[Kubernetes]yaml文件详解
4,Jenkins需要从svn上面拉取code,然后执行构建,构建完成之后,前端会生成dist,后端会生成war包.之后根据dockerfile制作镜像，然后在k8s上创建pod.在这个过程中,我们写了一个脚本,当Jenkins构建完成之后,会自动去执行.脚本内容如下(注意:此脚本内容仅供参考,#后面内容为注释内容)
#!/bin/sh -l
#定义在Harbor镜像仓库中,镜像的路径
image_path=reg.zll.com/library/frontend-dist:1.0.0
#构建前端镜像
#构建完成之后,再将构建后的镜像推到Harbor镜像仓库中
docker build -t $image_path .
docker push $image_path
#推到Harbor镜像仓库之后,删除本地镜像
docker rmi -f $image_path
#k8s部署,部署之前,先删除上次的相关内容
kubectl delete -f frontend-prod.yaml
#删除成功之后,重新创建,这样可以保证每次都是最新的
echo $WORKSPACE
kubectl create -f frontend-prod.yaml
到这里,我们应该对整体流程有了一个大概的了解.重点在于Jenkins的脚本执行.每次Jenkins构建完成之后,都会去执行脚本,这样当我们的代码有所更新时,我们不需要重新去部署,Jenkins会自动构建,构建完成之后,会自动生成相关镜像,并推到Harbor镜像仓库中.当我们需要进行相关项目部署时,只需要将镜像从Harbor仓库中拉取下来即可.
也就是说,使用k8s之后,我们需要做的就是:对项目进行更新迭代,需要时一条命令,从Harbor仓库中拉取镜像即可.其他都有脚本帮我们自动去完成.
我觉得在这里,Jenkins相当于一个桥梁,把我们自定义写的Dockerfile和yaml文件,和后面的k8s集群联系起来.
相比于以前,对代码更新之后,需要重新搭环境,重新走一遍流程来说,是不是方便了许多?节省了很多时间和精力,能够将注意力更好的放在开发上,而不是维护上.
而且统一到Harbor仓库中进行管理,需要时,从Harbor仓库中拉取镜像,这样也使得各个服务器拉取的镜像都是一样的.
以上,就是我在实际环境中,部署k8s流程的一个整体架构,适用于我们公司的需求,所以这篇博客只有参考价值,具体还是需要根据自己项目的实际需求来进行相关配置.
至于k8s集群的配置,我在这里就不做说明了,因为每个项目的需求不一样,而且在前面的文章中,我也做了相关说明,在这里就不重复了.
因为只研究了一个月左右的时间,所以上面难免有偏颇之处,如果您有发现,欢迎指出,我会核实改正.
实战完了,接下来的一段时间,我要去补充理论知识了,所以接下来的几篇文章可能还是关于k8s的相关内容,如果感兴趣,可以持续关注.
非常感谢您的阅读~