Тип бэкенда: 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 запускается автоматически. Вместо этого выберите другой бэкенд с поддержкой удалённого состояния и настройте его в корневом модуле. Это обеспечит автоматическое получение и сохранение состояния в правильном общем расположении всеми, кто работает с вашей конфигурацией, без специальных аргументов командной строки.