С версий 1.3-1.10 команда HashiCorp методично переносила эти операции в саму конфигурацию. Идея простая: если terraform - это инфраструктура как код (iac), то и операции над состоянием должны быть кодом, а не разовыми командами в терминале. Этот урок - сводка 2026 года: что появилось после книги, зачем это нужно и что реально стоит брать в работу уже сейчас. Глубокой практики не будет, по каждой фиче - суть и мини-пример. Подразумевается, что всё это работает и в OpenTofu (актуальные версии Terraform около 1.15, OpenTofu около 1.12), так что фичи доступны в обоих мирах, хотя сроки появления иногда отличаются.
moved, import, removed: операции над state как код
Первый и, пожалуй, самый полезный для повседневной работы блок - это декларативные операции над terraform state.
Блок moved (с версии 1.1) решает классическую боль: ты переименовал ресурс или вынес его в модуль, и terraform plan хочет уничтожить старый и создать новый. Раньше спасал terraform state mv, который надо помнить и выполнять руками на каждой машине. Теперь ты просто описываешь переезд в коде:
Код: Выделить всё
moved {
from = yandex_compute_instance.old_vm
to = yandex_compute_instance.app_vm
}
Блок import (с версии 1.5) - декларативный импорт. Вместо terraform import yandex_compute_instance.vm fd8... ты пишешь:
Код: Выделить всё
import {
to = yandex_compute_instance.legacy
id = "fhm8abc123def456"
}
resource "yandex_compute_instance" "legacy" {
# тут описание ресурса
}
Блок removed (с версии 1.7) - это зеркало moved. Тебе нужно убрать ресурс из управления Terraform, но не уничтожать его в облаке (например, отдаёшь сеть другой команде). Раньше - terraform state rm и молитва, что не опечатался. Теперь:
Код: Выделить всё
removed {
from = yandex_vpc_network.shared
lifecycle {
destroy = false
}
}
check, test и mocks: проверки и тестирование
Дальше - то, что приближает terraform к нормальной инженерной дисциплине.
Блок check (с версии 1.5) позволяет описывать утверждения о состоянии инфраструктуры, которые не ломают apply, но сигналят о проблеме. Это assert-уровня "так быть не должно", в отличие от жёсткого precondition. Пример - проверить, что у инстанса проставлен нужный объём памяти:
Код: Выделить всё
check "vm_memory" {
assert {
condition = yandex_compute_instance.app_vm.resources[0].memory >= 2
error_message = "У боевой машины должно быть минимум 2 ГБ памяти."
}
}
Test framework (с версии 1.6) - встроенный фреймворк тестов для модулей. Пишешь файлы .tftest.hcl, в них run-блоки, которые применяют твой модуль с разными переменными и проверяют выходы через assert. Команда - terraform test. Раньше для тестов модулей тащили Terratest на Go или самописные обёртки, теперь базовое покрытие есть из коробки.
Mocks (с версии 1.7) - логичное продолжение тестов. Можно подменять провайдеры, ресурсы и data-источники моками, чтобы terraform test не создавал реальную инфраструктуру и не требовал кредов. Тестируешь логику модуля (как считаются имена, как раскрывается for_each) без единого вызова к Yandex Cloud. Быстро и бесплатно.
provider-defined functions, ephemeral и Stacks
Третий блок - самые свежие и концептуально новые вещи.
Provider-defined functions (с версии 1.8) - функции, которые приносит сам провайдер, а не только встроенный набор Terraform. Раньше список функций (length, jsonencode, cidrhost и прочие) был зашит в ядро. Теперь провайдер может объявить собственные, и ты вызываешь их через namespace provider::имя::функция. Это снимает кучу костылей вокруг кодирования, парсинга и специфичных для платформы преобразований. Синтаксис вызова выглядит так:
Код: Выделить всё
output "decoded" {
value = provider::yandex::some_function(var.input)
}
Ephemeral resources и значения, плюс write-only атрибуты (с версии 1.10) - давняя боль с секретами наконец закрыта. Проблема: пароль от БД или токен нужен во время apply, но он не должен оседать в terraform state, который часто лежит в бакете и читается половиной команды. Ephemeral-ресурс читается заново на каждой фазе, никогда не пишется в state и всегда даёт временное (ephemeral) значение. Помечать переменные тоже можно как ephemeral. Write-only атрибуты ресурсов - это поля, которые ты передаёшь на запись, но Terraform их не сохраняет обратно в состояние. Итог: чувствительные данные перестают протекать в state-файл.
Terraform Stacks (превью, движется к общей доступности) - это про масштаб. Когда у тебя один и тот же стек надо раскатать в десять окружений или регионов, копипаста модулей и жонглирование workspace превращаются в ад. Stacks вводит два понятия: компоненты (component) - это переиспользуемые куски инфраструктуры на базе модулей, и развёртывания (deployment) - конкретные экземпляры стека с разными переменными. Описываются они в отдельных файлах (.tfstack.hcl и .tfdeploy.hcl). Грубо говоря, Stacks - это модули над модулями плюс оркестрация раскатки по многим целям. На 2026 год это во многом завязано на HCP Terraform и всё ещё дозревает, так что для прода - с оглядкой, но знать про направление полезно.
Типичные грабли
- Думают, что moved физически перемещает ресурс в облаке. Нет, он меняет только адрес в state. Сам ресурс не трогается.
- Забывают про lifecycle { destroy = false } в removed и удаляют ресурс из облака, хотя хотели только выкинуть его из управления. Внимательно с этим флагом.
- Сгенерированный через -generate-config-out конфиг считают готовым. Это черновик: туда попадают и вычисляемые атрибуты, и значения по умолчанию, всё надо вычитать руками.
- Путают версии. import-блок - это 1.5, а его for_each - уже 1.7. Если фича не работает, первым делом проверь terraform version.
- Считают, что sensitive = true защищает секрет в state. Нет, sensitive лишь прячет значение в выводе, в state оно лежит открытым текстом. По-настоящему не писать секрет в состояние умеют только ephemeral и write-only.
Руками, на любом тестовом проекте с провайдером Yandex Cloud:
- Создай простой yandex_compute_instance, примени. Затем переименуй ресурс в коде и добавь moved-блок. Сделай terraform plan и убедись, что пересоздания нет.
- Создай вручную через консоль или CLI любую сеть, потом импортируй её import-блоком с -generate-config-out. Посмотри, что нагенерилось, и приведи в порядок.
- Добавь check-блок с заведомо ложным условием и посмотри, как выглядит предупреждение в выводе plan.
- Напиши минимальный .tftest.hcl с одним run-блоком и прогони terraform test.
- Чем moved отличается от removed и что делает флаг destroy = false?
- В какой версии появился import-блок и зачем нужен флаг -generate-config-out?
- Почему sensitive = true не спасает секрет от попадания в terraform state и что использовать вместо этого?
- Что такое компонент и развёртывание в Terraform Stacks и какую задачу они решают?
Что запомнить: операции над state переехали в код - moved для переименований, import для подхвата существующего, removed для безопасного исключения. Качество подросло за счёт check, встроенного test и mocks. Расширяемость - через provider-defined functions. Секреты наконец перестали течь в состояние благодаря ephemeral и write-only. Stacks - заявка на масштаб, но пока дозревает. Бери в работу прямо сейчас moved, import, removed, check и тесты - это стабильно, полезно каждый день и поддерживается как в Terraform, так и в OpenTofu.
