Источник данных terraform_remote_state

Источник данных terraform_remote_state использует последний снимок состояния из указанного бэкенда состояния для получения выходных значений корневого модуля из другой конфигурации OpenTofu.

Источник данных terraform_remote_state можно использовать без необходимости подключать или настраивать провайдер. Он всегда доступен через встроенный провайдер с адресом источника terraform.io/builtin/terraform. Этот провайдер не включает никаких других ресурсов или источников данных.

Альтернативные способы обмена данными между конфигурациями​

Обмен данными с помощью выходных значений корневого модуля удобен, но у этого способа есть недостатки. Хотя terraform_remote_state предоставляет только выходные значения, пользователю этого источника необходим доступ ко всему снимку состояния, который часто содержит конфиденциальную информацию.

По возможности мы рекомендуем явно публиковать данные для внешнего использования в отдельном месте, а не обращаться к ним через удалённое состояние. Это позволяет применять разные правила доступа к общедоступной информации и снимкам состояния.

Для явного обмена данными между конфигурациями можно использовать пары типов управляемых ресурсов и источников данных в различных провайдерах, включая (но не ограничиваясь) следующие:

Ключевое преимущество использования отдельного явного хранилища конфигурации вместо terraform_remote_state заключается в том, что данные потенциально могут считываться и системами, отличными от OpenTofu, например системами управления конфигурацией или планировщиками на ваших вычислительных экземплярах. Поэтому мы рекомендуем выбрать хранилище конфигурации, которое потенциально смогут использовать и другие компоненты вашей инфраструктуры. Например:

• Если вы хотите предоставлять IP-адреса и имена узлов, можно публиковать их как обычные записи DNS A, AAAA, CNAME и SRV в частной зоне DNS, а затем настроить остальные компоненты инфраструктуры на использование этой зоны, чтобы находить объекты инфраструктуры с помощью встроенного системного DNS-резолвера.
• Если вы используете HashiCorp Consul, публикация данных в хранилище ключей и значений Consul или в каталоге служб Consul позволит также получать к ним доступ через Consul Template или блок template HashiCorp Nomad.
• Если вы используете Kubernetes, можно сделать Config Maps доступными для ваших подов.

Некоторые из перечисленных выше хранилищ данных специально предназначены для хранения небольших значений конфигурации, а другие представляют собой универсальные системы хранения двоичных объектов. Для таких универсальных систем можно использовать функцию jsonencode и функцию jsondecode соответственно для хранения и извлечения структурированных данных.

Можно скрыть детали реализации получения опубликованных данных конфигурации, создав модуль, содержащий только данные с необходимой конфигурацией источников данных и любыми необходимыми этапами постобработки, например декодированием JSON. Позднее этот модуль можно изменить, если вы перейдёте к другой стратегии обмена данными между несколькими конфигурациями OpenTofu.

Пример использования (бэкенд remote)​

data "terraform_remote_state" "vpc" {
  backend = "remote"

  config = {
    organization = "hashicorp"
    workspaces = {
      name = "vpc-prod"
    }
  }
}

resource "aws_instance" "foo" {
  # ...
  subnet_id = data.terraform_remote_state.vpc.outputs.subnet_id
}

Пример использования (бэкенд local)​

data "terraform_remote_state" "vpc" {
  backend = "local"

  config = {
    path = "..."
  }
}

resource "aws_instance" "foo" {
  # ...
  subnet_id = data.terraform_remote_state.vpc.outputs.subnet_id
}

Справочник аргументов​

Поддерживаются следующие аргументы:

• backend — (Обязательный) Используемый удалённый бэкенд.

• workspace — (Необязательный) Рабочее пространство OpenTofu, если бэкенд поддерживает рабочие пространства.

• config — (Необязательный; объект) Конфигурация удалённого бэкенда. Хотя этот аргумент указан как необязательный, большинству бэкендов требуется конфигурация.

  Объект config может использовать любые аргументы, допустимые в соответствующем блоке terraform { backend "<TYPE>" { ... } }. Подробности см. в документации выбранного вами бэкенда.

  Примечание

  Если конфигурация бэкенда требует вложенный блок, укажите его здесь как обычный атрибут со значением-объектом. (Например, workspaces = { ... } вместо workspaces { ... }.)

• defaults — (Необязательный; объект) Значения выходных параметров по умолчанию на случай, если файл состояния пуст или в нём отсутствует обязательный выходной параметр.

Справочник атрибутов​

Кроме перечисленных выше, экспортируются следующие атрибуты:

• outputs — объект, содержащий каждый корневой выходной параметр удалённого состояния.

Только выходные значения корневого модуля​

Для использования в других частях модуля доступны только выходные значения корневого уровня из снимка удалённого состояния. Данные ресурсов и выходные значения вложенных модулей недоступны.

Чтобы сделать выходное значение вложенного модуля доступным как выходное значение корневого модуля, необходимо явно настроить его передачу в корневом модуле. Например:

Например:

module "app" {
  source = "..."
}

output "app_value" {
  value = module.app.example
}

В этом примере выходное значение с именем example из модуля "app" доступно как выходное значение корневого модуля app_value. Если бы эта конфигурация не включала блок output "app_value", данные были бы недоступны через terraform_remote_state.