Terraform 1.15: динамічні джерела, застарілі змінні та перевірка стану

Перехід між minor-версіями Terraform не варто оцінювати лише за успішним terraform init -upgrade. Зміна core, провайдерів і модулів впливає на граф залежностей, state, lock-файл та результати плану. Безпечна міграція починається з відтворюваного середовища і закінчується перевіреним rollback.

Розділіть оновлення Terraform і провайдерів

Одночасне підняття CLI, кількох провайдерів і внутрішніх модулів створює план, у якому складно знайти джерело відмінності. Спершу зафіксуйте поточний .terraform.lock.hcl, версії модулів і backend. Потім протестуйте новий Terraform core зі старими дозволеними версіями провайдерів. Лише після цього оновлюйте залежності окремими змінами.

Lock-файл має бути частиною репозиторію. Для кількох платформ додайте контрольні суми через terraform providers lock, щоб локальний запуск на macOS і CI на Linux не переписували його по черзі. Завантаження провайдерів із внутрішнього mirror також потрібно перевірити до maintenance window.

План — це артефакт перевірки, а не формальність

Збережіть план старою і новою версіями на копії production state. Порівнюйте не лише кількість add/change/destroy, а конкретні атрибути, причини replacement і порядок залежностей. Несподіване «known after apply» може означати зміну схеми провайдера, а не реальну зміну хмарного ресурсу.

Особливо небезпечні масові replacement, зміни identity полів, мережевих правил, баз даних і кластерів. Для них потрібні окремі тестові ресурси або import/state move у контрольованому середовищі. Не застосовуйте великий план лише тому, що він синтаксично валідний.

State і backend потребують власного плану відновлення

Перед міграцією створіть резервну копію state незалежно від versioning backend. Перевірте, що команда вміє знайти конкретну версію об’єкта в S3, GCS чи іншому сховищі та відновити її без перезапису актуальних даних. Якщо змінюється формат state, повернення старого бінарника може бути недостатнім.

Блокування state також має працювати в тесті. Два паралельні apply під час міграції здатні пошкодити результат навіть за правильної версії Terraform. На час переходу обмежте запис до workspace, призупиніть автоматичні конвеєри і зафіксуйте одного відповідального оператора.

Рекомендована послідовність

1. Зафіксувати версії CLI, провайдерів, модулів, backend і робочий lock-файл.
2. Створити перевірену копію state та окремий тестовий workspace з репрезентативними ресурсами.
3. Запустити fmt, validate, тести модулів і план без оновлення провайдерів.
4. Порівняти плани старої та нової версій, пояснити кожну руйнівну або невідому зміну.
5. Оновлювати провайдери невеликими групами, що мають зрозумілого власника.
6. Застосувати canary workspace, перевірити реальний стан через API хмарного провайдера і тільки потім рухатися далі.

Критерії завершення

Міграція завершена, коли чистий terraform plan відтворюється в CI, lock-файл стабільний, drift не з’являється після apply, а команда виконала тест відновлення state. Окремо перегляньте політики доступу до backend і секретів CI — загальні принципи описані в матеріалі про секрети в CI/CD. Для кількох хмар корисно співвіднести зміну з реалістичною мультихмарною стратегією, а не множити однакові workspace без потреби.

Що документувати після першого apply

Збережіть фінальний план, версію CLI, lock-файл, commit модулів і посилання на change request. Для кожної ручної дії в cloud console створіть або виправте код: інакше наступний план відтворить drift. Якщо ресурс було переміщено через moved block або state command, задокументуйте стару й нову адресу та умову видалення тимчасового правила.

Після apply перевірте не лише Terraform state, а реальний control plane провайдера: маршрути, політики, health, репліки й encryption. Provider може успішно записати бажаний стан, хоча залежний сервіс ще виконує асинхронну операцію. Для таких ресурсів визначте окремий smoke test.

Через один робочий цикл повторіть plan із чистого runner. Це знаходить невраховані environment variables, локальні credentials і кеш. Якщо результат залежить від конкретного ноутбука, міграцію не можна вважати завершеною.

Першоджерела: офіційний каталог релізів Terraform та upgrade guides для конкретної версії.