如何解决 for

不幸的是，for_each这里的使用隐藏在另一个模块terraform-google-modules/service-aounts/google中，所以我们也需要看看那个模块，看看它是如何使用project_roles输入变量的。首先，让我们看一下错误消息所指的具体资源块：

resource "google_project_iam_member" "project-roles" {
  for_each = local.project_roles_map_data

  project = element(
    split(
      "=>",
      each.value.role
    ),
    0,
  )

  role = element(
    split(
      "=>",
      each.value.role
    ),
    1,
  )

  member = "serviceAount:${google_service_aount.service_aounts[each.value.name].email}"
}

这里发生了一些有些复杂的事情，但与我们在这里看到的最相关的是这个资源配置正在创建多个基于local.project_roles_map_data. 现在让我们看一下local.project_roles_map_data：

  project_roles_map_data = zipmap(
    [for pair in local.name_role_pairs : "${pair[0]}-${pair[1]}"],
    [for pair in local.name_role_pairs : {
      name = pair[0]
      role = pair[1]
    }]
  )

这里稍微复杂一点，这对我们正在寻找的东西并不重要；这里要考虑的主要事情是，这是构造一个映射，其键是从元素 0 和元素 1 构建的local.name_role_pairs，它直接在上面声明，以及local.names它所指的：

  names                 = toset(var.names)
  name_role_pairs       = setproduct(local.names, toset(var.project_roles))

因此，我们在这里了解到的是，invar.names和 in 的值var.project_roles都有助于for_each该资源上的键，这意味着这些变量值都不应该包含在应用步骤期间动态决定的任何内容。

但是，我们还（上面）了解到，project和的role参数google_project_iam_member.project-roles是从您提供的两个列表中的元素的前缀派生的，names以及project_roles您自己的模块调用中的元素的前缀。

让我们回到我们开始的地方，记住所有这些额外的信息：

module "service_aounts" {
  source  = "terraform-google-modules/service-aounts/google"
  version = "4.0.3"

  project_id    = module.project-factory.project_id
  generate_keys = "true"
  names         = ["backend-runner"]
  project_roles = [
    "${module.project-factory.project_id}=>roles/cloudsql.client",
    "${module.project-factory.project_id}=>roles/pubsub.publisher"
  ]
}

我们已经了解到，names并且project_roles两者都必须只包含配置中决定的静态值，因此不适合使用module.project-factory.project_id，因为直到在应用步骤期间生成随机项目 ID 后才会知道。

但是，我们也知道该模块期望project_roles（ 之前的部分=>）中每个项目的前缀是有效的项目 ID，因此没有任何其他值可以合理使用。

因此我们有点陷入困境：第二个模块有一个相当尴尬的设计决策，它试图从同一值派生本地实例键和对真实远程对象的引用，这两种情况有冲突要求。但这不是您创建的模块，因此您无法轻松修改它以解决该设计怪癖。

鉴于此，我看到了两种可能的前进方法，虽然都不理想，但都有一些警告是可行的：

您可以采用提供的错误消息作为解决方法，首先要求 Terraform 计划和应用第一个模块中的资源，然后在项目 ID 已经确定并记录在状态：

terraform apply -target=module.factory
terraform apply

尽管必须分两步进行初始创建很烦人，但它至少只对初始创建此基础架构很重要。如果您稍后对其进行更新，则无需重复此两步过程，除非您以需要生成新项目 ID 的方式更改了配置。

在完成上述操作时，我们看到这种生成和返回随机项目 ID 的方法是基于您在配置中var.random_project_id设置的第一个模块的可选方法。"true"没有它，project_id输出将只是您给定name参数的副本，这似乎是通过引用根模块变量来静态定义的。

除非您特别需要项目 ID 上的随机后缀，否则您可以不random_project_id设置，因此只需将项目 ID 设置为与您的 相同的静态值var.project_name，这应该是可以用作for_each键的可接受值。

理想情况下，第二个模块将设计为将其使用的值（例如键）与用于引用真实远程对象的值分开，因此可以使用远程对象的随机后缀名称，但静态定义本地对象的名称。如果这是您控制下的模块，那么我会建议进行类似的设计更改，但我认为该第三方模块当前不寻常的设计（将多个值打包到带有分隔符的单个字符串中）是一种折衷方案希望保持与模块早期迭代的向后兼容性。