Назначение состояния OpenTofu

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

Как вы увидите из приведённых ниже причин, состояние необходимо. А в сценариях, где OpenTofu, возможно, мог бы обойтись без состояния, для этого пришлось бы перенести огромную часть сложности из одного места (состояния) в другое (концепцию замены).

Сопоставление с реальным миром​

OpenTofu требуется своего рода база данных для сопоставления конфигурации OpenTofu с реальным миром. Например, когда в конфигурации есть ресурс resource "aws_instance" "foo", OpenTofu использует это сопоставление, чтобы знать, что ресурс resource "aws_instance" "foo" представляет собой реальный объект с идентификатором экземпляра i-abcd1234 в удалённой системе.

Для некоторых провайдеров, например AWS, OpenTofu теоретически мог бы использовать что-то вроде тегов AWS. В ранних прототипах OpenTofu фактически не было файлов состояния, и использовался этот метод. Однако вскоре возникли проблемы. Первая серьёзная проблема была простой: не все ресурсы поддерживают теги, и не все облачные провайдеры поддерживают теги.

Поэтому для сопоставления конфигурации с ресурсами в реальном мире OpenTofu использует собственную структуру состояния.

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

Метаданные​

Помимо сопоставлений ресурсов с удалёнными объектами, OpenTofu также должен отслеживать метаданные, например зависимости ресурсов.

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

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

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

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

Производительность​

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

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

Для небольших инфраструктур OpenTofu может обращаться к вашим провайдерам и синхронизировать последние значения атрибутов всех ресурсов. Это поведение OpenTofu по умолчанию: при каждом планировании и применении OpenTofu синхронизирует все ресурсы в состоянии.

Для крупных инфраструктур запрос каждого ресурса выполняется слишком медленно. Многие облачные провайдеры не предоставляют API для одновременного запроса нескольких ресурсов, а время ожидания ответа для каждого ресурса составляет сотни миллисекунд. Кроме того, облачные провайдеры почти всегда ограничивают частоту запросов к API, поэтому OpenTofu может запрашивать только определённое количество ресурсов за заданный промежуток времени. Пользователи OpenTofu с крупными инфраструктурами активно используют флаг -refresh=false, а также флаги -target/-exclude, чтобы обойти эти ограничения. В таких сценариях кэшированное состояние считается достоверной записью.

Синхронизация​

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

Удалённое состояние — рекомендуемое решение этой проблемы. Полнофункциональный сервер состояния позволяет OpenTofu использовать удалённую блокировку, чтобы предотвратить случайный одновременный запуск OpenTofu двумя или более пользователями и гарантировать, что каждый запуск OpenTofu начинается с последней обновлённой версии состояния.