解读与部署（三）：基于 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 能力。

来源：诺普博客

作者：陈计节