通过通用数据过滤器使用terraform_remote_state

Question

我想了解何时建议在常见的数据过滤器方法上使用terraform_remote_state。

我看到诸如图像之类的情况，这些情况不受另一个地形状态的管理，在这种情况下，显而易见的（也是唯一的）选择是数据过滤器。 但是，在大多数情况下，我可以在terraform_remote_state和其他数据过滤器之间进行选择。在这件事上，我找不到官方建议。

让我们举个例子 （以下代码无法按原样运行，并且简化为仅显示主要思想）：

让我们假设我们有一个具有自己状态/工作区的中央组件

vault / main.tf：

terraform {
  backend "azurerm" {
    storage_account_name = "tfstates"
    container_name       = "tfstates"
    key                  = "vault/all.tfstate"
  }
}

provider "openstack" {
  version     = "1.19"
  cloud       = "openstack"
}

resource "openstack_networking_subnetpool_v2" "vault" {
  name              = "vault"
  prefixes          = ["10.1.0.0/16"]
  min_prefixlen     = 24
  default_prefixlen = 24
}

resource "openstack_networking_network_v2" "vault" {
  name           = "vault"
}

resource "openstack_networking_subnet_v2" "vault" {
  name            = "vault"
  network_id      = openstack_networking_network_v2.vault.id
  subnetpool_id   = openstack_networking_subnetpool_v2.vault.id
}

// Make cidr available for terraform_remote_state approach
output "cidr" {
  value = openstack_networking_subnet_v2.vault.cidr
}

....

---

选项1：使用数据过滤器在另一个tf工作区中将Vault cidr列入白名单

postgres / main.tf：

terraform {
  backend "azurerm" {
    storage_account_name = "tfstates"
    container_name       = "tfstates"
    key                  = "postgres/all.tfstate"
  }
}

provider "openstack" {
  version     = "1.19"
  cloud       = "openstack"
}

data "openstack_identity_project_v3" "vault" {
  // assuming vault is setup in its own project
  name = "vault"
}

data "openstack_networking_network_v2" "vault" {
  name      = "vault"
  tenant_id = data.openstack_identity_project_v3.vault.id
}

data "openstack_networking_subnet_v2" "vault" {
  name      = "vault"
  tenant_id = data.openstack_identity_project_v3.vault.id
}

resource "openstack_networking_secgroup_v2" "postgres" {
  name        = "postgres"
  description = "Allow vault connection"
}

resource "openstack_networking_secgroup_rule_v2" "allow-vault" {
  direction         = "ingress"
  ethertype         = "IPv4"
  security_group_id = openstack_networking_secgroup_v2.postgres.id
  remote_ip_prefix  = data.openstack_networking_subnet_v2.vault.cidr 
}

---

选项2：使用terraform_remote_state在另一个tf工作区中将Vault cidr列入白名单

postgres / main.tf：

terraform {
  backend "azurerm" {
    storage_account_name = "tfstates"
    container_name       = "tfstates"
    key                  = "postgres/all.tfstate"
  }
}

provider "openstack" {
  version     = "1.19"
  cloud       = "openstack"
}

data "terraform_remote_state" "vault" {
  backend "azurerm" {
    storage_account_name = "tfstates"
    container_name       = "tfstates"
    key                  = "vault/all.tfstate"
  }
}

resource "openstack_networking_secgroup_v2" "postgres" {
  name        = "postgres"
  description = "Allow vault connection"
}

resource "openstack_networking_secgroup_rule_v2" "allow-vault" {
  direction         = "ingress"
  ethertype         = "IPv4"
  security_group_id = openstack_networking_secgroup_v2.postgres.id
  remote_ip_prefix  = data.terraform_remote_state.vault.cidr 
}

我个人更喜欢terraform_remote_state，因为从模块的角度来看，它似乎不太模棱两可，而且更具声明性（即，您有意识地声明了其他工作空间应该使用的输出变量）。但是，我对是否有确凿的理由对此感兴趣，或者是否有一些我不知道的最佳实践感到好奇。

是否存在针对这种情况的官方推荐方法？

Answer 1

@martin-atkins在HashiCorp论坛上发表了精彩的answer。

但是，他没有对此线程做出响应，因此为了完成我在总结我的要点。

---

适当的HashiCorp方法将是第三个选择：将参数写入配置存储（例如Consul）。

这带来了很多好处：

1. 您可以控制要使用其他工具的内容 （问题选项2的好处：显式发布）
2. 您在Terraform工作空间之间没有紧密的联系（问题的选项1：去耦的好处）。也就是说，变量生产者与变量消费者分离。
3. 其他工具，包括Terraform本身，以后都可以使用这些值。

---

我建议您阅读original answer，因为它的内容更深。