Источник данных 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.