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

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

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 对象分离，您将默认保留历史工件，因此如果您部署并发现问题，您可以选择切换回已知良好的现有工件只需使用较旧的工件版本重新运行部署步骤 (Terraform)。如果您改为直接使用 Terraform 管理工件，Terraform 将在创建新工件之前删除您的旧工件，因为这是 Terraform 的预期使用模型。

在 HashiCorp 指南Serverless Applications with AWS Lambda and API Gateway 中有关于此模型的更多详细信息。您没有说.zip此处的文件是针对 Lambda 的，但类似的原则适用于任何版本化工件。这类似于其他部署模型的工作流程，例如为每个版本构建单独的 Docker 镜像或 AMI；在每种情况下，Terraform 都更适合用于选择由其他工具构建的现有工件的过程，而不是用于创建这些工件本身。