OpenTofu после Terraform: миграция без потери state

Коротко. Сделайте резервную копию кода и state, зафиксируйте версии провайдеров, проверьте используемые возможности Terraform, установите OpenTofu, выполните init и plan без изменений. Если конфигурации читают чужой remote state, переносите сначала потребителей, а потом владельца state. Первый apply должен быть маленьким, обратимым и наблюдаемым.

Когда миграция вообще нужна

Нужна, когда у команды есть осознанное решение по лицензированию, поддержке или открытому стеку. Не нужна ради строчки в резюме и красивого поста. Если Terraform стабильно управляет инфраструктурой, а у вас нет тестового контура, владельца state и окна отката, сначала исправьте процесс. Менять инструмент поверх хаоса — просто получить новый хаос с другим логотипом.

Инвентаризация до первой команды

• выпишите все root modules, workspaces и backend;
• сохраните копию каждого state и проверьте, что она читается;
• зафиксируйте lock-файлы и версии провайдеров;
• найдите remote-state зависимости между конфигурациями;
• отдельно отметьте cloud-функции и синтаксис, которые могут быть специфичны конкретной реализации;
• остановите параллельные apply на время миграции.

State нельзя считать резервным только потому, что он лежит в S3. Проверьте версионирование объекта, блокировку и процедуру восстановления. Бэкап, который никто не пробовал открыть, — религия, а не контроль.

Безопасная сухая проверка

tofu version
tofu init -reconfigure
tofu validate
tofu plan -out=migration.plan
tofu show migration.plan

Ожидаемый результат первого plan — отсутствие инфраструктурных изменений. Если видите массовую замену ресурсов, не нажимайте apply «посмотреть, что будет». Сравните версии provider, адреса ресурсов, backend, переменные и lock-файл. Отдельно проверьте sensitive outputs: смена формата вывода не должна случайно раскрыть секреты в CI.

Почему важен порядок remote state

Представьте конфигурацию network, чей state читает конфигурация application. Во время смешанного периода совместимость чтения важнее красивого порядка по названиям. Сначала переведите потребителя application, убедитесь, что он продолжает читать Terraform state, и лишь затем переводите network, который этот state пишет. Для цепочки зависимостей начинайте с листьев и двигайтесь к основанию.

Не включайте OpenTofu-специфичные возможности, пока старые потребители ещё должны читать результат Terraform. Сначала завершите совместимый перенос, затем отдельным изменением используйте новые функции.

Что поменять в CI

1. Замените бинарник и зафиксируйте его версию.
2. Оставьте отдельные jobs для fmt, validate и plan.
3. Публикуйте plan как артефакт и применяйте именно проверенный plan.
4. Не передавайте долгоживущие cloud-ключи, если доступна краткоживущая федерация.
5. Сохраните блокировку окружения, чтобы два apply не боролись за один state.
6. Запишите команду возврата на прежний pipeline до начала работ.

Первый apply

Не делайте первым изменением пересборку VPC. Добавьте тег, маленькое правило или другой контролируемый объект в тестовом окружении. Сверьте plan, примените, повторно получите plan без изменений и проверьте реальный ресурс через API облака. Затем выполните откат тем же процессом. Так вы проверите запись state, locking, права CI и обратимость, а не только синтаксис HCL.

Как превратить миграцию в сильный кейс

В репозитории покажите карту зависимостей, обезличенный backend, версии инструментов, фрагмент CI, чеклист до и после, безопасный тестовый change и решение об откате. На собеседовании важна не фраза «мигрировал на OpenTofu», а объяснение, почему выбрали порядок, где лежит state, кто держит lock и что вы делаете при неожиданном destroy.

Перед практикой разберите базовые практики Terraform. Если инфраструктура выкатывается через Git, продолжите практикой GitOps и Argo CD.

Частые вопросы

Можно просто заменить terraform на tofu?
На простой конфигурации часто да, но производственная миграция требует проверки state, провайдеров, backend и зависимых конфигураций.

Надо конвертировать HCL?
Большая часть существующей конфигурации сохраняется. Любые несовместимости надо ловить validate и plan, а не предполагать.

Что считать завершением?
Все конфигурации работают через новый CI, plan чистый, state резервируется и восстанавливается, а команда выполнила маленький apply и откат.