Источник данных 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 доступными вашим Pod.

Некоторые перечисленные выше хранилища данных специально предназначены для хранения небольших значений конфигурации, тогда как другие представляют собой универсальные системы хранения больших двоичных объектов. Для таких универсальных систем можно использовать функцию 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.