Terraform 1.0: compatibility promise и конец workaround'ов для 0.14/0.15
HashiCorp выпустила Terraform 1.0. Главное - не новые фичи, а compatibility promise: конфиги на 1.x не сломаются при обновлении внутри major-версии.
Terraform 1.0 GA: стабильное API, compatibility promise и production-ready статус от HashiCorp
HashiCorp объявила Terraform 1.0 общедоступным. Если ждёте списка революционных фич - его нет. Релиз намеренно тихий: те же команды, тот же HCL, та же логика state. Но именно это и важно.
Что на самом деле изменилось
Terraform 1.0 - это прежде всего сигнал. HashiCorp берёт на себя публичное обязательство: конфигурации, написанные сейчас, будут работать на любой версии 1.x без сломанных изменений. Нет deprecation-сюрпризов в минорных релизах, нет неожиданно пропавших аргументов, нет «а мы же предупреждали в changelog».
До 1.0 путь от 0.12 к 0.13, от 0.13 к 0.14, от 0.14 к 0.15 каждый раз требовал прогнать terraform 0.13upgrade, прочитать что именно поменялось, поправить конфиги. Иногда ломались CI-скрипты, иногда - outputs с sensitive-значениями, иногда - ссылки на провайдеры. Мы разбирали это на примере 0.14 применительно к lock-файлу и на 0.15 с sensitive outputs - каждый раз был список «что посмотреть перед апгрейдом».
С 1.0 это обещают прекратить. Внутри major-версии - никаких breaking changes. Апгрейд с 1.0 на 1.5 должен быть как обновление nginx: просто поменял бинарь, убедился что plan не выдаёт неожиданного, двигаешься дальше.
Что значит «production-ready» от HashiCorp
Формально Terraform и так использовался в production повсеместно - никого не смущало что на бирке было «0.x». Но вопрос «а вы уверены что это production-ready?» от безопасников и архитекторов клиентов возникал регулярно. Теперь на него есть простой ответ: 1.0, GA, вот changelog, вот commitment.
Для managed-сопровождения это тоже удобно: проще обосновывать технические решения когда инструмент формально вышел из нулевой версии. Не потому что ничего не изменилось по факту - просто стало меньше вопросов, которые не про технику.
Что конкретно включает в себя stability guarantee:
- Язык HCL и его семантика - всё что работает в 1.0, работает в 1.x.
- CLI-интерфейс - флаги, команды, коды выхода. Скрипты не ломаются от апгрейда.
- State-формат - файл
.tfstateчитается всеми версиями 1.x в обе стороны. - Remote state - взаимодействие между модулями через
terraform_remote_stateостаётся стабильным.
Провайдеры и модули из Terraform Registry - не часть этого обещания. Они версионируются отдельно, и здесь lock-файл из 0.14 остаётся главным инструментом контроля.
Что мы делаем прямо сейчас
На большинстве клиентских проектов в managed-сопровождении мы сидели на 0.14, часть уже на 0.15. Решение простое: переводим всё на 1.0.
Переход технически тривиален - 1.0 принимает state от 0.14 и 0.15 без конвертации. terraform init, убедиться что plan чистый, всё.
Параллельно убираем накопившиеся workaround'ы:
Явные пины версий. В нескольких проектах у нас были constraints вида version = "= 0.14.10" - зафиксированная точная версия Terraform в CI, потому что нельзя было доверять что ~> 0.14 не принесёт что-то неожиданное в минорном обновлении. С lock-файлом и 1.0 это избыточно - хватит ~> 1.0 в required_version.
Ветки в CI под версию. В паре пайплайнов был условный выбор образа с Terraform в зависимости от проекта, потому что разные проекты сидели на разных 0.x. Теперь стандартизируем на одном образе с 1.0.
Скрипты с deprecated-флагами. В 0.15 часть старых CLI-флагов стала ошибкой, и мы уже поправили скрипты тогда. Но остались несколько самописных обёрток со старыми паттернами - они работали потому что CI был пришпилен к старой версии. Сейчас самое время почистить.
Что не изменилось и не должно
Принципиальных архитектурных изменений нет. Remote state через S3/GCS/Azure Blob - как работал, так работает. Provider registry - без изменений. Модульная структура конфигов - та же. terraform plan и terraform apply делают то же что делали.
Это не минус. Это и есть смысл 1.0: не переизобрести инструмент, а сказать «вот это теперь стабильно».
Одно практическое наблюдение: обновить Terraform на проекте без ревью плана - всё равно нельзя, даже с compatibility promise. terraform plan после апгрейда надо смотреть глазами. Провайдеры могли обновиться, provider schema могла поменяться, и план покажет дифф там, где его не ждёшь. Обещание про совместимость касается самого Terraform, не всей экосистемы вокруг него.
Где сейчас
Переход начали, несколько проектов уже на 1.0. Workaround'ы убираем по мере касания каждого проекта - не отдельной задачей, а по ходу работы. Неожиданностей не встретили.
Главный результат который ждём не технический, а организационный: единая версия Terraform на всех проектах, никаких «а это на 0.14, а это на 0.15, а вот это ещё на 0.13 и мы боимся трогать».