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