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

После настройки параметров облачного бэкенда для рабочего каталога необходимо выполнить 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"]
    }
   }
 }