app/app.tf
resource "heroku_app" "app" { name = "${var.name}" region = "eu" organization = { "name" = "${var.organization}" } config_vars = ["${var.configuration}"] } resource "heroku_addon" "deploy_hook" { app = "${heroku_app.app.name}" plan = "deployhooks:http" config = { url = "${var.deployhook_url}" } } output "name" { value = "${heroku_app.app.name}" }可用在服务声明中：
stack/some_service.tf
module "app" { source = "../app" name = "some-service" configuration = { SOME_ENV_VARIABLE = "value" } pipeline_id = "000000-9207-490a-b050-617b01ef79f3" deployhook_url = "https://some.deploy.hook" }这对我们来说是一个重大的变化，因为我们把很多重复的资源附加到每个应用程序——监控、日志收集、部署钩子等等。但这也带来了一个问题——由于某些原因，相同的工件有时候并不代表相同的资源。也就是说，它们不支持计数参数，但计算参数在应用条件逻辑或按照每个克隆进行服务迭代时却是非常关键的。确切地说，我们不应该这样做：
stack/services.tf（这不是真的）
module "app" { source = "../app" name = "some-service-${var.clone[count.index]}" configuration = "${var.configuration[count.index]}" ... }我们必须重复每个克隆的定义：
stack/services.tf
module "clone1_app" { source = "../app" name = "some-service-clone1" configuration = "${var.clone1Configuration}" } module "clone2_app" { source = "../app" name = "some-service-clone2" configuration = "${var.clone2Configuration}" }这个问题也有望在可预见的未来得到解决。
6. 不稳定的资源作为一款功能丰富的0.x版本软件，Terraform存在一大堆小问题。其中一个问题是，有些资源并不会保持稳定的状态。对我们来说，问题是SNS主题订阅策略——我们针对服务所做的所有事情，只要包含订阅了SNS的队列，Terraform就会去修改它们（无论是否有意义）。这样可能会导致混淆，尤其是对于第一次接触Terraform的人来说。虽然这个问题是供应商局部问题，并且很可能会得到修复，但在修复之前总归是要注意的。
7. 一些小细节我们遇到的另一个小问题是无法使用依赖于某些状态的计数值（在模块中），例如：
resource "heroku_app" "sample" { count = "${lookup(var.some_map, "enable_sample_app", 0)}" name = "sample-app" ... }如果在模块中定义了上述的内容，你将会得到一条这样的消息：无法计算count的值…这真的很烦人，特别是当你看到Hashicorp的解释，说可以使用-target来逐个初始化资源。
8. 如何处理秘钥？Terraform文件之所以不容易保存，其中一个原因是不知道该把秘钥保存在哪里。有几种方法可以解决这个问题：
Hashicorp使用了他们的Vault——虽然这是可行的，但它使整个设置变得更加复杂，感觉有点矫枉过正。
与Vault类似，你可以使用AWS的KMS来存储秘钥——但它同样有复杂性方面的问题。
使用私有git存储库，只要电脑不被偷，就不会有什么问题。
如果你是在CD/CI服务器上运行作业，可以将秘钥保存在环境变量中，但在一个复杂的系统中，可能就难以维护太多的环境变量。
你可以将秘钥保存在本地，并使用专门用于配置的机器，但对于有一定规模的团队来说，这样做是不行的。