我是新来的，所以请原谅我。这种情况适用于三大云提供商。一个同事想要一个生成.tfplan的管道，然后.tfplan文件被"提升";通过QA，准备，制作。请记住，这些环境根据环境有不同的资源名称和对象GUIDS(自然)和标记。
据我所知,这是行不通的,因为计划文件的引用可以很具体的根据需要处理的现有资源,在每个各自的环境。
我知道TF中的工作区。此时此刻，我不想被提及此事。让我们假设它们不是一个选项，因为更高级的同事认为它们是一个配置难题。我只是找不到任何有记录的TF工作流程，其中这甚至是可行的。但除此之外，这毫无意义。该范例的另一个问题是，它意味着开发环境需要以与您希望最终在生产环境中扩展资源相同的方式来扩展资源。本质上……一个是开发扩展计划，然后将其从QA转移到生产……因此不可避免地将生产中的扩展需求与开发联系起来。我错了吗?
在正常的Terraform工作流中，您可能"推广"的工件;通过各个部署阶段的是配置(包含.tf文件的模块目录树)，而不是计划文件。
"plan"在Terraform中，是提供者提出的一组操作，通过将配置与以前的状态进行比较，使远程系统与新的配置相匹配。每个部署阶段都有自己的"当前状态"。因此，每个都需要创建自己的计划，尽管您可以为每个人使用相同的配置，以便告诉Terraform期望的状态是相同的，即使达到该状态的步骤可能因环境而异，这取决于相关对象已经配置的方式。
Terraform有一些安全检查，目的是在您尝试将保存的计划文件应用于不同的状态快照时捕获，所以在大多数情况下，这样做只会立即返回一个错误。然而，Terraform的启发式检测不可能是完美的(它在不完整的信息下工作)，所以它仍然是一个好主意，注意只在它打算使用的上下文中使用保存的计划文件。
我知道TF中的工作区。我不想被提及这个，此时。我只是找不到任何有记录的TF工作流程是否可行
很抱歉这么说，但是工作空间绝对是你所需要的。我将发布一些可能有用的例子，几年前我一直在研究TF。
考虑到您在同一个AWS帐户中有多个环境，您可以设置如下:
main.tf:
resource "aws_s3_bucket" "my_bucket" {
bucket = "my-bucket-${local.env}"
tags = {
Environment = local.env
}
}
settings.tf:
locals {
env = terraform.workspace
}
这样，您需要创建工作区:
terraform workspace create dev
terraform workspace create prod
选择当prod工作区,起程拓殖计划将显示类似的东西:
# aws_s3_bucket.my_bucket will be created
+ resource "aws_s3_bucket" "my_bucket" {
+ bucket = "my-bucket-prod"
+ tags = {
+ "Environment" = "prod"
}
}
，当选择dev时:
# aws_s3_bucket.my_bucket will be created
+ resource "aws_s3_bucket" "my_bucket" {
+ bucket = "my-bucket-dev"
+ tags = {
+ "Environment" = "dev"
}
}
因此，您将能够为每个工作空间创建一个S3资源，而无需复制它们。这是使用工作空间的一种简单方法，但是如果您正在使用CI，您可以传递一个$ENVIRONMENTenv变量，并使用它来选择正确的工作空间。
terraform workspace select $ENVIRONMENT
terraform apply --auto-approve
如果你使用多个帐户，只要告诉我，我可以编辑我的答案，放一些例子。:)