Terramate脚本功能中变量复用的设计与实践

在基础设施即代码(IaC)领域，Terramate作为新兴的编排工具，其脚本功能(script)正逐步成为自动化工作流的核心组件。近期社区提出的变量复用需求，揭示了脚本开发中一个常见痛点：如何在多个命令间共享计算逻辑而不产生代码冗余。

变量复用场景分析

典型场景出现在需要基于环境变量或元数据动态生成文件名时。例如：

1. 将Terraform计划文件按栈ID命名后上传至S3
2. 在CI环境中注入构建ID到产物名称
3. 组合多个全局变量生成中间路径

传统实现方式存在明显缺陷：

• 命令级重复：每个命令重复相同的变量计算逻辑
• 环境变量污染：通过Shell变量可能引发并行执行冲突
• 可维护性差：修改逻辑需同步多个位置

Terramate的解决方案演进

现有模式评估

当前脚本功能支持直接命令编排，但缺乏变量抽象层。开发者不得不采用两种变通方案：

1. 命令参数重复：在每个命令中重复计算表达式
2. Shell脚本封装：通过bash子进程实现变量共享

后者虽然灵活，但存在安全隐患（如未处理的特殊字符）和跨平台兼容性问题。

设计中的lets块

受Terramate自身generate_hcl模块启发，建议引入lets代码块：

lets {
  plan_file = "${terramate.stack.id}-${global.job_id}.tfplan" 
}

特性优势：

• 作用域隔离：变量仅限当前脚本可见
• 类型安全：HCL原生类型系统保障
• 求值时机：在命令执行前静态解析

临时解决方案技术细节

在官方方案落地前，可采用bash子进程实现类似效果：

PLAN_NAME=$(jq -n \
  --arg stack ${terramate.stack.id} \
  --arg jobid ${global.job_id} \
  '$stack+"-"+$jobid+".tfplan"')

注意事项：

1. 必须设置set -e确保错误传播
2. 对美元符号需转义处理\$
3. 复杂表达式建议使用jq等工具处理JSON逃逸

架构设计启示

该需求反映了配置代码化(Configuration-as-Code)系统的核心挑战：

• 声明式vs过程式：lets块采用声明式而bash偏向过程式
• 抽象层次：应在合适层级提供变量抽象（项目级/栈级/脚本级）
• 执行模型：需考虑未来并行执行对共享状态的影响

Terramate团队表示该特性已纳入开发计划，其实现将参考现有generate_hcl模块的变量处理机制，保持语言特性的一致性。对于急需该功能的用户，建议通过代码评审确保临时方案的健壮性，待官方支持发布后再进行迁移。