Инициализация и миграция

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

При выполнении tofu init в следующих случаях OpenTofu предложит выбрать, нужно ли переносить состояние из существующих рабочих пространств.

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

2. Миграция из бэкенда remote: Если рабочий каталог уже был подключен к облачному бэкенду с помощью бэкенда remote, OpenTofu сможет продолжить использовать те же рабочие пространства облачного бэкенда. Вам потребуется заменить блок бэкенда remote блоком cloud.

Миграция из локального состояния или бэкендов состояния​

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

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

Поэтому OpenTofu предложит переименовать рабочие пространства рабочего каталога по шаблону, основанному на их текущих именах. Это может указывать на то, что эти конкретные рабочие пространства используют общую конфигурацию. Типичная стратегия — <COMPONENT>-<ENVIRONMENT>-<REGION> (например, networking-prod-us-east, networking-staging-us-east).

Миграция из бэкенда remote​

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

Бэкенд remote был основной реализацией облачных бэкендов в версиях Terraform от 0.11.13 до 1.0.x. Для OpenTofu и Terraform версии 1.1 или более поздней мы рекомендуем использовать встроенную интеграцию cloud, поскольку она обеспечивает более удобную работу и различные улучшения.

Замена блока​

При переходе с бэкенда remote на блок cloud OpenTofu продолжит использовать тот же набор рабочих пространств облачного бэкенда. Замените блок backend "remote" эквивалентным блоком cloud.

Одно рабочее пространство​

Если вы использовали одно рабочее пространство с аргументом name, измените метку блока на cloud.

terraform {
-  backend "remote" {
+  cloud {
    organization = "my-org"

    workspaces {
    name = "my-app-prod"
    }
   }
 }

Несколько рабочих пространств​

Если вы использовали несколько рабочих пространств с аргументом prefix, замените его блоком cloud с аргументом tags. Можно указать любое количество тегов, чтобы различать рабочие пространства рабочего каталога. Для начала можно использовать прежний префикс.

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

terraform {
-  backend "remote" {
+  cloud {
     organization = "my-org"

    workspaces {
-      prefix = "my-app-"
+      tags = ["app:mine"]
    }
   }
 }