我对地形和地形很陌生。现在我有点困惑为什么要使用terragrumt而不是tfvars文件。
我的场景是为其中一个应用程序创建多个资源，如web应用程序、azure sql、存储帐户。该应用程序有多个环境，如dev、qa、prod，还部署在weu、eus、wus2等多个区域。我试图用tfvars文件对此进行参数化。
我的目录结构看起来像：
app1/storageaccount.tf
/webapp.tf
/sqldb.tf
/main.tf
/variables.tf
/dev.tfvars
/prod-weu.tfvars
/dev-weu.tfvars
/qa-eus.tfvars
.......
我使用tfvars文件来传递环境、位置变量等。我甚至可以将状态文件名、订阅名作为变量。因此，在这里，我试图了解terragrumt将如何比tfvars更有帮助。对于每个环境/区域，我只能有一个tfvar文件，而不是为terragrunt创建的多个hcl文件。
你能在这里放些光吗？
谢谢，桑托什
简短的回答是"terragrumt不是这样工作的">，terragrunt从根本上改变了部署terraform的方式，增加了更多的功能，更重要的是简化了代码。
让我们从您的部署开始：
即使你只有一堆terraform文件在不同的环境或地区部署完全相同的东西，你也需要为每次部署交换backend.tf文件，因为terraform不允许在其中使用变量，这会使你的环境暴露在错误的apply中，这是危险的，不仅使用简单的变量，还使用terragrumt提供的附加函数(例如，您的bucket可以设置为："mycorp-${get_aws_account_id()}-tfstate"，从而产生mycorp-123456892123-tfstate(。
另一个很酷的内置函数是run_cmd()，它与makefile一起使用，可以让您使用任何脚本自动设置变量。我让开发人员运行测试部署，我在当前日期时间中添加了一个变量集，设置了一个"；CreationDatetime"；标签
然后，由于很少有一个基础设施永远这么小，总有一天有人需要在其中一个环境中添加一些稍微不同的东西。这就是您将开始使用这样的东西只在测试中部署的地方，例如。。
count = var.test_env == 1 ? 1 : 0
这只是一个开始，它会越来越多地发生，prod和staging可能会存活下来，dev/test/etc每个月都会开始漂移一点，这通常会导致代码非常难以理解，有很多基于.rfvar文件的条件，非常难以管理。
那么，terragrunt如何帮助tfvars做不到的事情呢
使用terragrunt，您根本不需要在部署中使用.tf文件。您将任何非第三方模块的内容转换为模块，然后将模块引用到每个文件夹中的terragrunt.hcl文件中。
是的，你会有多个文件夹，这是真的，但每个文件夹通常只有一个文件，terragrunt.hcl，设置模块的输入，要部署的模块，等等。
正如你所看到的，你的代码不会改变，你只会添加资源作为"占位符"；在每个目录中。您将能够重用相同的代码，并为每个环境添加更改，而无需对地形进行任何更改。
这并不意味着你不能将terragrumt与tf文件一起使用，我这样做是因为我需要terragrum的能力来将输出设置为第二次部署的输入。
这是在保留您的代码"；DRY"；，正如他们所说。此外，您将获得更多功能，仅举几个例子：
- Terragrunt为使用
sops加密的机密添加了本地支持 - 它允许重试失败的部署
- 可以在部署之前或之后运行命令
- 等等
我建议阅读这篇伟大的博客文章，它正是关于这个的