技能介绍

要解决的问题

当同一套基础设施需要同时交付 Terraform HCL、Ansible playbook 和 Kubernetes manifests 时，参数很容易散落在多个目录里，dev/staging/prod 的差异也常靠复制粘贴维护。结果是一个参数改动要翻多个文件，环境覆盖关系不可追溯，生成出来的配置缺少一致的变量继承模型。

工作方式

这个技能把 Jinja2 当作基础设施即代码的渲染层：共享参数文件负责定义变量，Jinja2 模板负责消费变量并输出 HCL、YAML 或其他文本形态。它的核心能力是变量继承与分层环境覆盖：先基于基础参数生成公共结构，再按环境叠加差异，最终产出 Terraform 配置、Ansible playbook 或 Kubernetes manifests。模板中的占位符允许以接近 Python 的写法表达条件、循环和格式化逻辑，Jinja2 会在运行时把模板编译为优化后的 Python 代码执行。

典型路径可以概括为：

定义共享参数：公共 region、镜像、规格、标签、命名空间等。
编写 Jinja2 模板：复用继承和片段，避免每类资源各写一套完整文本。
叠加环境 overlay：为 dev/staging/prod 提供差异化值。
渲染目标配置：输出 Terraform、Ansible 或 Kubernetes 所需的文件内容。

适用边界

它适合做“参数到配置文本”的转换，不适合把全部部署逻辑塞进模板。按 Jinja2 的上游理念，模板用于表达结构，复杂应用逻辑应尽量留在 Python 或上层编排里；如果模板里出现大量条件分支，应先判断是否应该重构参数或生成器。生成结果仍需配合 Terraform、Ansible、Kubernetes 自身的校验与测试，模板本身不替代 plan/apply、lint、dry-run 或安全扫描。