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