问如何在“`terraform`”中创建带有时间戳的文件？

EN

变量默认值尤其是常量值，但是本地值允许从变量派生的任意表达式：

variable "override_s3_key" {
  default = ""
}

locals {
  s3_key = var.override_s3_key != "" ? var.override_s3_key : "deploy-${timestamp()}.zip"
}

然后，您可以在配置的其他地方使用local.s3_key来访问这个派生值。

尽管如此，Terraform的目的是创建长期运行的基础设施对象，因此包括时间戳通常是(但不是总是如此！)表示设计上的问题。在这个特殊的例子中，它看起来像是使用Terraform来创建用于部署的应用程序构件，这是Terraform可以做的事情，但是Terraform通常不是这类工作的最佳工具。

相反，考虑将构建分割成两个单独的步骤，其中构建步骤是使用您选择的任何单独工具--甚至可能只是一个shell脚本--实现的，并在S3中生成一个版本(或时间戳)工件。然后，可以使用该版本或时间戳参数化Terraform配置，以实现“部署”步骤：

variable "artifact_version" {}

locals {
  artifact_s3_key = "deploy-${var.artifact_version}.zip"
}

这种分离的一个优点是，通过将版本化的工件从长期存在的Terraform对象中分离出来，您将默认保留历史构件，因此，如果您部署并发现了一个问题，您只需使用旧的工件版本重新运行deploy步骤(Terraform)，就可以选择切换回已知的、良好的现有工件。如果您使用Terraform直接管理工件，Terraform将在创建新工件之前删除旧工件，因为这是Terraform的预期使用模型。

HashiCorp指南基于AWS Lambda和API网关的无服务器应用程序中有关于这个模型的更多细节。您并没有说这里的.zip文件是指定给Lambda的，但是有一个类似的原则适用于任何版本的工件。这类似于其他部署模型的工作流，例如为每个版本构建单独的Docker映像或AMI；在每种情况下，Terraform更好地用于选择由其他工具构建的现有工件的过程，而不是创建这些工件本身。