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

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

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

Использование источников данных​

Доступ к источнику данных осуществляется через особый вид ресурса, известный как ресурс данных, объявляемый с помощью блока data:

data "aws_ami" "example" {
  most_recent = true

  owners = ["self"]
  tags = {
    Name   = "app-server"
    Tested = "true"
  }
}

Блок data запрашивает у OpenTofu чтение данных из указанного источника данных ("aws_ami") и экспорт результата под заданным локальным именем ("example"). Это имя используется для обращения к ресурсу из других частей того же модуля OpenTofu, но не имеет значения за пределами модуля.

Источник данных и имя вместе служат идентификатором ресурса и поэтому должны быть уникальными в пределах модуля.

В теле блока (между { и }) задаются ограничения запроса, определяемые источником данных. Большинство аргументов в этом разделе зависят от источника данных; в данном примере most_recent, owners и tags — это аргументы, определённые специально для источника данных aws_ami.

Чтобы отличать ресурсы данных от основных типов ресурсов (объявляемых с помощью блока resource), последние называют управляемыми ресурсами. Оба типа ресурсов принимают аргументы и экспортируют атрибуты для использования в конфигурации, но управляемые ресурсы заставляют OpenTofu создавать, обновлять и удалять объекты инфраструктуры, тогда как ресурсы данных заставляют OpenTofu только читать объекты. Для краткости управляемые ресурсы часто называют просто «ресурсами», если их значение понятно из контекста.

Аргументы источников данных​

Каждый ресурс данных связан с одним источником данных, который определяет тип считываемого объекта (или объектов) и доступные аргументы ограничений запроса.

Каждый источник данных, в свою очередь, относится к провайдеру — подключаемому модулю OpenTofu, предоставляющему набор типов ресурсов и источников данных, обычно относящихся к одной облачной платформе или платформе локальной инфраструктуры.

Большинство элементов в теле блока data определяются выбранным источником данных и относятся к нему; эти аргументы могут в полной мере использовать выражения и другие динамические возможности языка OpenTofu.

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

Поведение ресурсов данных​

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

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

Подробнее о том, что означает зависимость ресурса данных от других объектов, см. в разделе Зависимости ресурсов данных. В таком случае все результирующие атрибуты этого ресурса данных будут неизвестны на этапе планирования, поэтому их нельзя использовать там, где значения должны быть полностью известны.

Метааргументы​

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

О следующих метааргументах можно прочитать на отдельных страницах:

• depends_on — для указания скрытых зависимостей
• enabled — для создания условного экземпляра одного ресурса в соответствии с выражением
• count — для создания нескольких экземпляров ресурса в соответствии с заданным количеством
• for_each — для создания нескольких экземпляров в соответствии с отображением или набором строк
• provider — для выбора конфигурации провайдера, отличной от конфигурации по умолчанию
• lifecycle — для настройки жизненного цикла

Настройка жизненного цикла​

Блок lifecycle внутри блока data позволяет настроить некоторые аспекты поведения OpenTofu, связанные с экземплярами ресурса на разных этапах его жизненного цикла.

data "example" "example" {
  # ...normal resource arguments...

  lifecycle {
    # ...lifecycle arguments...
  }
}

В блоке lifecycle для ресурса данных поддерживаются следующие аргументы и типы вложенных блоков:

• enabled (bool) — определяет, будет ли OpenTofu считывать ресурс данных. Если задано значение false, ресурс исключается из конфигурации, как если бы его не существовало. Если задано значение true (по умолчанию), ресурс работает в обычном режиме.

  Подробнее см. в описании метааргумента enabled.

• Блоки precondition и postcondition, описанные в разделе Пользовательские условия.

Локальные источники данных​

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

Например, локальные источники данных используются для рендеринга шаблонов, чтения локальных файлов и рендеринга политик AWS IAM.

Локальные источники данных работают так же, как и все остальные источники данных, но данные результатов существуют только временно во время операции OpenTofu и вычисляются заново при создании каждого нового плана.

Зависимости ресурсов данных​

Для ресурсов данных действует такое же поведение при разрешении зависимостей, как и для управляемых ресурсов. Указание метааргумента depends_on в блоках data откладывает чтение источника данных до применения всех изменений зависимостей.

Чтобы источники данных получали как можно более актуальную информацию в самых разных сценариях использования, аргументы, напрямую ссылающиеся на управляемые ресурсы, обрабатываются так же, как если бы ресурс был указан в depends_on. При необходимости такого поведения можно избежать, косвенно ссылаясь на значения управляемого ресурса через значение local, если только сам ресурс данных не содержит пользовательские условия.

Проверки пользовательских условий​

С помощью блоков precondition и postcondition можно указать предположения и гарантии относительно работы источника данных. В следующем примере создаётся постусловие, проверяющее, что у AMI заданы правильные теги.

data "aws_ami" "example" {
  id = var.aws_ami_id

  lifecycle {
    # The AMI ID must refer to an existing AMI that has the tag "nomad-server".
    postcondition {
      condition     = self.tags["Component"] == "nomad-server"
      error_message = "tags[\"Component\"] must be \"nomad-server\"."
    }
  }
}

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

Подробнее см. в разделе Проверки пользовательских условий.

Конфигурации провайдеров, отличные от конфигурации по умолчанию​

Как и для ресурсов, если у модуля есть несколько конфигураций одного провайдера, можно указать, какую из них использовать, с помощью метааргумента provider:

data "aws_ami" "web" {
  provider = aws.west

  # ...
}

Дополнительные сведения см. в разделе Метааргумент provider ресурса.