基于 Kubernetes 的 CICD 基础设施即代码

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

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

本文，我们深入探讨其中 CI/CD 软件部分的“基础设施即代码”的实现原理。

变量模板引擎

在工作坊中，由于所有与会者使用的都是同一个 Kubernetes 集群，因此我们需要一种方法来标识当前用户。Kubernetes 的命名空间提供的逻辑隔离功能可以很轻松地实现这个效果。因此，我们要为每个工作坊与会者创建他的一批命名空间：

• cicd-<suffix> 用于部署 CI/CD 软件

• dev-<suffix> 作为“开发环境”，部署微服务

• stage-<suffix> 作为“预生产环境”，部署微服务

显然，对于每一个与会者来说，这里的 suffix 会有所不同，因此它是一个变量。除了在启动安装 CI/CD 软件时需要使用，这个变量还需要以某种形式保存到 Jenkins 上，因为当 Jenkins 运行部署任务时，它也需要知道目标命名空间的名字。

为了处理变量，我们自己发明了一个小型的“模板引擎”。其作用是，使用变量文件中指定的值，替换各个文件中的变量，输出最终的内容。这个模板引擎以双美元符号 $$ 作为变量起始字符。打开 cicd-infra/jenkins.yaml 并搜索 $$ 就可以发现其中大量地引用了各个变量。

模板引擎的实现位于 ./tmpl.sh 脚本文件，它能从指定的变量文件和环境变量读入各个变量的值，并将待处理文件中的变量占位符替换为对应的值，最后向标准输出（stdout）打印最终的文件内容。借助流水线指令 |，这些内容随后被 kubectl apply -f - 命令读取，