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

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

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

Узлы графа​

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

• Узел ресурса — представляет один ресурс. Если для ресурса задан метапараметр 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.