Terraform 1.15: чому `validate` тепер треба переперевірити у CI, особливо якщо ви використовуєте `-backend-config`

Що змінилося

Terraform 1.15.0 непомітно підкрутив одну з найчутливіших частин CI: terraform validate тепер перевіряє backend block. Тобто команда дивиться, чи існує backend, чи є обов’язкові атрибути і чи проходить його власна валідація.

Це гарна ідея — поки ви не запускаєте Terraform через -backend-config. У 1.15.1 HashiCorp саме тому прибрав валідацію атрибутів усередині backend block: вона конфліктувала з workflow, які підставляють частину конфігурації ззовні.

Простіше кажучи: 1.15.0 зробив validate суворішим, а 1.15.1 повернув йому сумісність із реальними CI-сценаріями.

Чому це важливо

У багатьох командах terraform validate — це перший швидкий gate. Він має бути дешевим, стабільним і передбачуваним. Коли його поведінка змінюється, з’являються два ризики:

• старий пайплайн починає падати без змін у коді;
• команда починає ігнорувати validate, бо «він знову вередує».

Найчастіше це болить там, де:

• state лежить у віддаленому backend;
• параметри backend приходять із секретів або окремого файлу;
• terraform init і terraform validate запускаються в різних кроках;
• module source уже використовує variables або locals.

У такій схемі дрібний розсинхрон між init і validate легко перетворюється на нічний фейл, який виглядає випадковим. А ще гірше — на фейл, який усі обходять руками.

Схема, яку варто мати в голові

У здоровому пайплайні terraform init бере той самий backend-конфіг, який ви справді використовуєте, а terraform validate перевіряє конфігурацію так, щоб не зламати цей сценарій. Саме тому 1.15.1 важливіший за голий 1.15.0, якщо у вас є -backend-config.

Як перевірити свій CI

1. Знайдіть усі місця, де запускається Terraform

Почніть не з коду, а з інвентаризації:

• .github/workflows/*.yml
• shell-скрипти в репозиторії
• make-цілі
• будь-які wrapper-скрипти для init або validate

Шукайте саме terraform init, terraform validate і -backend-config.

2. Переконайтеся, що init і validate бачать один і той самий backend

Якщо init отримує backend.hcl з одного місця, а validate запускається без нього, ви вже маєте різні умови. У таких випадках 1.15.0 може почати сваритися, хоча проблема не в коді, а в схемі запуску.

Типовий сценарій має виглядати так:

terraform init \
  -backend-config=backend.hcl \
  -input=false

terraform validate

Якщо backend.hcl формується динамічно, не ховайте це від validate. Потрібна та сама правда, а не симуляція.

3. Проганяйте реальний сценарій на 1.15.1

Якщо ви вже бачите або підозрюєте проблему, не застрягайте на 1.15.0. Для backend-config безпечніший мінімум — 1.15.1 або новіший patch-реліз.

Якщо хочете короткий тест на міграцію, порівняйте:

• вашу поточну версію;
• Terraform 1.15.0;
• Terraform 1.15.1.

Так ви одразу побачите, чи фейл був реальною помилкою, чи наслідком короткого проміжного регресу.

4. Окремо перевірте module source

Terraform 1.15 ще й дозволив variables і locals у module source та version attributes. Це зручно, але саме такі зміни люблять вилазити боком у старих пайплайнах.

Якщо у вас модулі збираються динамічно, перевірте:

• чи тягнуться вони з правильного джерела;
• чи не ламається розв’язання версій;
• чи не з’явився новий фейл у init замість validate.

5. Не втратьте сигнал у логах

У 1.15 також покращили логування terraform init: часові мітки стали точнішими до мілісекунд. Це не головна фіча релізу, але для flaky CI вона дуже доречна.

Що не робити

• Не думайте, що validate — це лише перевірка синтаксису.
• Не лишайте 1.15.0 у production CI, якщо у вас є -backend-config.
• Не запускайте init з одним backend-конфігом, а validate з іншим.
• Не сприймайте support for variables in module source як дозвіл змінити все без повторного тесту.
• Не вимикайте validate, якщо він почав падати. Спершу зрозумійте, що саме він уже навчився бачити.

Практичний висновок

Коротко: Terraform 1.15.0 корисно показав, що backend — це не другорядна деталь, а частина валідації. Але якщо ви користуєтеся -backend-config, 1.15.1 — це безпечніша точка входу.

Що робити сьогодні:

• знайти всі CI-кроки з Terraform;
• звірити, що init і validate бачать однаковий backend;
• перевірити сценарій на 1.15.1;
• окремо прогнати модулі, де module source залежить від variables або locals;
• залишити в пайплайні один зрозумілий шлях, а не два майже однакові.

Менше сюрпризів у validate — менше ночей, коли інфраструктура вирішує поговорити з вами через червоний CI.