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

Источники данных позволяют 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 ресурса.