Concourse中vars与params的区别及使用场景选择通用经验准则

Concourse中的vars和params本质作用完全不同，不是可互相替代的选项：

• vars属于pipeline配置层的模板变量，仅用于Concourse解析pipeline配置时的插值替换，替换逻辑在pipeline配置生效前就完成了，不会传入任务运行的容器环境。
• params属于任务运行层的环境变量，配置值会在任务启动时直接注入到容器的操作系统环境中，专供任务内部运行的脚本、程序读取调用。

你给出的配置示例看起来值是一样的，但实际生效逻辑天差地别：

params:
  COMMAND: deployment.deploy # 这个值会成为容器内的环境变量，脚本里可以直接读取$COMMAND调用
vars:
  command: deployment.deploy # 这个值仅能在pipeline的YAML配置里做插值用，容器里完全读不到

params的适用场景 #

满足以下任意一种情况就应该用params：

• 你需要把值传递给任务内部运行的脚本、二进制程序使用：所有需要在任务运行时读取的参数，都只能通过params传递，vars完全无法覆盖这个场景。
• 你需要传递敏感信息：Concourse默认会对params中的敏感值做日志脱敏处理，输出日志时会自动把匹配到的敏感值替换为***，避免密码、Token等信息泄露，vars没有对应的脱敏机制。
• 你需要复用通用任务定义：params支持在调用任务时动态覆盖取值，不需要修改任务本身的配置，比如你有一个通用的执行部署命令的任务，不同环境部署只需要传入不同的COMMAND参数即可，不用为每个环境单独写一份任务定义。

通用选择准则 #

判断用vars还是params只需要一个核心标准：

这个值的使用方是Concourse的pipeline配置解析器，还是任务容器内运行的程序？
前者用vars，后者直接选params即可。

内容的提问来源于stack exchange，提问作者kharandziuk