Тип бэкенда: local

Тип: расширенный

Локальный бэкенд хранит состояние в локальной файловой системе, блокирует его с помощью системных API и выполняет операции локально.

Пример конфигурации​

terraform {
  backend "local" {
    path = "relative/path/to/terraform.tfstate"
  }
}

Конфигурация источника данных​

data "terraform_remote_state" "foo" {
  backend = "local"

  config = {
    path = "${path.module}/../../terraform.tfstate"
  }
}

Переменные конфигурации​

Поддерживаются следующие параметры конфигурации:

• path — (необязательно) путь к файлу tfstate. По умолчанию используется файл "terraform.tfstate" относительно корневого модуля.
• workspace_dir — (необязательно) путь к нестандартным рабочим пространствам.

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

Для конфигураций, содержащих блок backend "local" или использующих локальный бэкенд по умолчанию, поскольку бэкенд не указан, большинство команд, читающих или записывающих снимки состояния из бэкенда, принимают следующие дополнительные аргументы:

• -state=FILENAME — переопределяет имя файла состояния при чтении предыдущего снимка состояния.

• -state-out=FILENAME — переопределяет имя файла состояния при записи новых снимков состояния.

  Если использовать -state без -state-out, OpenTofu будет использовать имя файла -state и для -state, и для -state-out, а это означает, что OpenTofu перезапишет входной файл, если создаст новый снимок состояния.

• -backup=FILENAME — переопределяет имя файла по умолчанию, которое локальный бэкенд обычно выбирает динамически для создания резервных копий при записи нового состояния.

  Если использовать -state без -backup, OpenTofu будет использовать имя файла -state в качестве префикса для формирования имени файла резервной копии. Можно использовать -backup=- (то есть задать имя файла, состоящее только из символа ASCII-дефиса), чтобы полностью отключить создание резервных копий.

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

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

Эти три параметра не влияют на конфигурации, в которых выбран другой тип бэкенда.

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