解读与部署(三):基于 Kubernetes 的微服务部署即代码

在基于 Kubernetes 的基础设施即代码一文中,我概要地介绍了基于 Kubernetes 的 .NET Core 微服务和 CI/CD 动手实践工作坊使用的基础设施是如何使用代码描述的,以及它的自动化执行过程。

如果要查看基于 Kubernetes 的基础设施即代码架构全图,以及实现代码,请回到文章基于 Kubernetes 的基础设施即代码。

本文,我们深入探讨其中 微服务部署部分的“基础设施即代码”的实现原理。

一般来说,在一个团队,CI/CD 软件不会经常部署。与此不同,时常处于开发之中的微服务的则会经常部署。此外,在部署到集群之前,通常开发人员还需要在某个“本机”环境对其所开发的微服务进行预先测试和调试。于是,在工作坊的环境中,我们在设计微服务的“持续部署即代码”时,也模拟正常的微服务开发情景进行了相关设计。

大体上,工作坊在部署微服务时,有如下几个方面协同工作:

•微服务所需的公用基础设施

•微服务本身在 Kubernetes 上的部署配置

•微服务的 CI/CD 过程

其中“微服务公用基础设施”部分的自动化原理在我们第一篇文章中已有介绍,这里主要介绍后两者。

微服务的 Kubernetes 部署

之前介绍过,在需要部署微服务时,调用 dev-services 项目根目录的 provision-services.sh 脚本文件将触发微服务的部署。脚本中的实际过程,还是会使用微服务项目根目录的 k8s.yaml 来完成部署。部署时,脚本还是会利用之前介绍过的模板引擎传入变量文件。

也就是说,用于部署工作坊中的微服务的 Kubernetes 资源文件都是以单个 k8s.yaml 文件的形式在各个微服务自己的代码仓库中维护的。这体现出“微服务自己知道如何部署自己”的自助原则。工作坊的微服务大致可分为两类,一类是纯后台服务,另一类是提供 Web 界面的服务。维护微服务的团队可根据需要自行定制用于在 Kubernetes 集群上部署它自己的资源文件。如果使用 kustomize,还可以以这个文件为入口,利用嵌套、变量等功能编写更易于维护的 Kubernetes 资源文件。

微服务的 CI/CD 过程

工作坊中的微服务,它们的 CI/CD 过程同样是由微服务自身所主导的。在上一篇文章基于 Kubernetes 的 CICD 基础设施即代码中我们介绍过微服务的部署流水线在 Jenkins 启动之后就已经内置创建好了。但实际上流水线虽然创建好了,但流水线中运行的内容却确实是由微服务自己控制和维护的。

这得益于 Jenkins 中基于 Jenkinsfile 的“流水线即代码”技术。简单来说,Jenkins 在运行流水线之前,会先去微服务代码库下载这个 Jenkinsfile 文件,再根据其中的内容决定如何运行流水线。查看各个微服务的代码库就会发现,它们的根目录都存在一个 Jenkinsfile,虽然整体结构都差不多,但具体细节还是有一些差异的。

在 Jenkinsfile 中,我们声明了微服务持续集成和持续部署的几个典型阶段:

1.检出代码

2.编译应用

3.生成新版容器镜像

4.部署新版容器镜像

其中,上述第 2 步要求 Jenkins 具有支持 .NET Core SDK 的运行器(Slave)节点 dotnet;而第 3、4 步则要求 Jenkins 具有支持 kubelet 和 docker 的节点 image-builder。而它们,则是由 Jenkins 中的 Kubernetes 插件提供的支持。

当流水线运行到这些步骤时,插件将负责按需地在 Kubernetes 集群上启动具有这些功能的 Slave 节点。具体的启动方法(比如,要使用的镜像、要挂载的存储等)都在“CICD 基础设施即代码”的过程中被自动写入。

虽然在工作坊中,我们各个示例微服务的流水线的结构都大致类似;但在实际项目中,有了上述特性的支持,各个团队可以自己定制自己的微服务的流水线形态。举例来说,在上述第 3 步,生成容器镜像时,会用到 Dockerfile。

与 Jenkinsfile 一样,其中调用的 Dockerfile 也同样是自己维护的。因此,微服务团队能够很轻松地对 Dockerfile 进行定制,即使要使用不同的编程语言平台也都能轻松掌控。

在现在这种体系下,微服务团队对自己的 CI/CD 过程几乎具有完全的掌握能力。

总结

在部署微服务的公用基础设施及微服务本身的过程中,我们也结合使用了不同的自动化技术:

1.借助 Pod 附加执行(exec),可以直接在容器中执行程序。我们在 SqlServer 部署完成之后,向其中导入数据库结构和种子数据时用到了这种技术;

2.借助 Jenkins 上的 Kubernetes 插件定制 Jenkins 按需启动的运行器(Slave)节点的运行;

3.使用 Dockerfile 自由定制运行微服务所用的容器;

4.使用 Jenkinsfile 配合由 Jenkins 提供的流水线和 Groovy 脚本语法可以轻松实现“流水线即代码”。

作为这一系列的最后一篇,这里也简单回顾一下工作坊对“基础设施即代码”的实践。目前,这个系列基本上涵盖了从 CI/CD 基础设施,到微服务的持续部署的两个关键环节,这也是开发团队经常会打交道的两个环节。

工作坊的场景相对简单,并没有实现诸如存储、数据库迁移和流量切换等高级话题,也没有考虑安全性和与周边工具的集成等领域,更没有涉及 Kubernetes 集群本身以及它可能依赖的基础平台的更广泛意义上的“基础设施即代码”。所以,如果希望把工作坊的实践应用到实际项目中,还需要经过一系列改进。

基于“基础设施即代码”的实践,可以直接把能够运行的基础设施配置代码本身当作操作文档。这一思想不仅有助于快速而可靠地构建基础设施,它还能够让开发人员拥有更多灵活性,促进跨部门协作时关于职责划分的新讨论,最终有助于团队间能力的融合,共同组建 DevOps 能力。

来源:诺普博客

作者:陈计节

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址