Граф ресурсов

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

Общие сведения о теории графов и краткий обзор её применения в OpenTofu см. в презентации HashiCorp 2016 года Применение теории графов к инфраструктуре как коду. В этой презентации также рассматриваются некоторые идеи, похожие на изложенные в следующем руководстве.

Узлы графа​

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

• Узел ресурса — представляет один ресурс. Если задан метапараметр count, для каждого значения count будет создан отдельный узел ресурса. К этому узлу привязаны конфигурация, различия, состояние и другие данные изменяемого ресурса.

• Узел конфигурации провайдера — представляет этап полной настройки провайдера. На этом этапе провайдеру передаётся блок конфигурации, например учётные данные безопасности AWS.

• Метузел ресурса — представляет группу ресурсов, но сам по себе не выполняет никаких действий. Он используется для удобства при работе с зависимостями и для более наглядного отображения графа. Этот узел присутствует только для ресурсов, у которых значение параметра count больше 1.

При визуализации конфигурации с помощью tofu graph можно увидеть все эти узлы.

Построение графа​

Граф строится в несколько последовательных этапов:

1. На основе конфигурации добавляются узлы ресурсов. Если есть различия (план) или состояние, эти метаданные привязываются к каждому узлу ресурса.

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

3. Для создания рёбер между ресурсами используются явные зависимости, заданные метапараметром depends_on.

4. Если состояние существует, в граф добавляются все ресурсы-сироты. Ресурсы-сироты — это ресурсы, которые больше не присутствуют в конфигурации, но есть в файле состояния. У ресурсов-сирот никогда не бывает связанной с ними конфигурации, поскольку файл состояния её не хранит.

5. Ресурсы связываются с провайдерами. Для этих провайдеров создаются узлы конфигурации, а рёбра строятся так, чтобы ресурсы зависели от настройки соответствующих провайдеров.

6. В конфигурациях ресурсов и провайдеров анализируются интерполяции для определения зависимостей. Ссылки на атрибуты ресурсов превращаются в зависимости от ресурса, содержащего интерполяцию, к ресурсу, на который она ссылается.

7. Создаётся корневой узел. Он указывает на все ресурсы и нужен для того, чтобы у графа зависимостей был единый корень. При обходе графа корневой узел игнорируется.

8. Если есть различия, выполняется обход всех узлов ресурсов, чтобы найти ресурсы, которые будут уничтожены. Такие узлы ресурсов разделяются на два: один узел уничтожает ресурс, а другой создаёт его (если ресурс создаётся заново). Узлы необходимо разделить, поскольку порядок уничтожения часто отличается от порядка создания, и поэтому действия нельзя представить одним узлом графа.

9. Проверяется, что в графе нет циклов и есть один корневой узел.

Обход графа​

Для обхода графа используется стандартный обход в глубину. Обход выполняется параллельно: обработка узла начинается, как только обработаны все его зависимости.

Параллелизм ограничивается с помощью семафора, чтобы слишком большое количество одновременных операций не перегружало ресурсы компьютера, на котором запущен OpenTofu. По умолчанию одновременно обрабатываются не более 10 узлов графа. Это число можно задать с помощью флага -parallelism в командах plan, apply и destroy.

Настройка -parallelism считается продвинутой операцией и обычно не требуется для использования OpenTofu. Она может быть полезна в некоторых особых случаях или при отладке проблем OpenTofu.

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