Terratest: чому ручна перевірка Terraform не масштабується
Ручне тестування інфраструктури виглядає надійним рівно до першої зміни, яка проходить рев'ю і тихо ламає середовище. Інфраструктура як код описує бажаний стан, але саме описання ніхто не виконує — інженер читає terraform plan очима й вирішує, що все виглядає розумно.
Перевірка terraform у такому режимі зводиться до звірки diff з очікуваннями в голові, а не до фактичного застосування й вимірювання результату.
Далі з'являється розбіжність опису й середовища. Хтось поправив правило фаєрвола через консоль, доопрацював політику доступу вручну, додав ресурс поза репозиторієм — і наступне застосування або затирає ручну правку, або падає через конфлікт. Дрейф накопичується безшумно, бо в репозиторії все чисто, а в реальності вже ні.
Помилки прав доступу та залежностей вилазять у найгірший момент — у середині застосування змін. Роль створилася, прив'язка політики не проходить, частина ресурсів уже існує, частина ні, стан заблоковано.
Відкат робиться руками, з пам'яті, під тиском: чим більше модулів задіяно, тим вищий шанс залишити середовище в проміжному стані.
Звідси й межа масштабування: чим більше середовищ і модулів, тим дорожча кожна ручна перевірка і тим менша ймовірність, що її взагалі проведуть.
Terratest закриває це тим, що розгортає справжню інфраструктуру в ізольованому проєкті, перевіряє її доступність і поведінку кодом і зносить після прогону. Розбираємо, як така перевірка вбудовується в конвеєр випуску.
Що дає автоматична перевірка інфраструктурного коду
Автоматична перевірка інфраструктурного коду відповідає на три питання: що саме зламається, скільки чекати відповіді та чи збіжиться результат у робочому середовищі з тим, що бачили на тестовому. Нижче — ефекти, які видно у вимірюваних величинах.
Які класи відмов зникають
План застосування описує намір, але не перевіряє, що після нього сервіс відповідає. Тести на Terratest розгортають середовище з нуля й перевіряють результат: доступність по мережі, прив'язку прав, наявність ресурсу після повторного застосування.
Зникає цілий клас відмов «конфігурація застосувалася, але сервіс не піднявся» — такі помилки ловляться до злиття, а не в момент викату.
Скільки часу займає перевірка зміни
Ручна перевірка зміни в тестовому середовищі займає години: підняти, застосувати, переконатися. Один прогін на ізольованій копії вкладається в хвилини, а прогони різних гілок ідуть паралельно.
Відповідь «зміна безпечна» розробник отримує до злиття, і черга на викат не простоює в очікуванні перевіряльного.
Передбачуваність викату в робочі середовища
Сценарій перевірки один і той самий для тестового та робочого середовища — відрізняються лише набори змінних і масштаб. Додається перевірка повторного застосування: якщо другий прогін не змінює план, конфігурація ідемпотентна й не «дрейфує» з часом.
Частка викатів, що потребують ручних правок після застосування, знижується, а відкат спирається на той самий відпрацьований сценарій.
Terratest і kitchen-terraform: підходи до перевірки конфігурацій
Перевірку конфігурацій рідко будують на одному способі: статичний аналіз ловить друкарські помилки й порушення правил ще до першого застосування, але поведінку реальної інфраструктури він не підтверджує.
Тому в зрілій схемі рівні поєднують — від швидких перевірок при кожній зміні до прогону на ізольованому полігоні перед викаткою в робочий контур.
Terratest і kitchen-terraform закривають саме інтеграційний рівень: вони піднімають ізольований полігон, застосовують конфігурацію й перевіряють фактичний результат, а потім знімають за собою ресурси.
Локальний емулятор інфраструктури помітно швидший, але не відтворює поведінку провайдера. Нижче — варіанти, між якими реально обирають.
Варіанти перевірки
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Статичний аналіз | На кожній зміні, до побудови плану: друкарські помилки, заборонені конструкції, відхилення від правил | Не знає фактичного стану середовища, дає хибні спрацьовування |
| Розбір плану змін | На рев'ю: видно, що саме буде створено, змінено або видалено | План не гарантує збігу з результатом застосування |
| Прогін на ізольованому полігоні | Перед прийманням: перевіряються зв'язності, права доступу, мережеві маршрути | Потрібен окремий контур і час на розгортання та знесення ресурсів |
| Локальний емулятор інфраструктури | У циклі розробки: швидкий зворотний зв'язок, перевірка модулів окремо | Не відтворює поведінку провайдера та крайові ефекти |
| Ручний прогін інженером | Разові зміни та те, що поки не автоматизовано | Не повторюється, не захищає від регресій |
На практиці рівні комбінують: статичні правила й розбір плану — при кожній зміні, полігон — на етапі приймання, емулятор — у повсякденній роботі інженера. Далі розберемо, як це вкладається у складання й хто відповідає за кожен рівень.
Етапи впровадження перевірок інфраструктурного коду
Перевірки інфраструктурного коду впроваджуємо покроково — якщо вивалити відразу весь набір тестів, команда отримає десятки червоних збірок і перестане їм вірити. Тому спочатку фіксуємо, що саме може зламатися в середовищі, і лише потім пишемо перевірки під ці ризики.
- Аудит інфраструктури. Розбираємо описи ресурсів, модулі та історію змін: де правка одного ресурсу тягла за собою перестворення залежних, де конфігурація розходилася з фактичним станом. Результат — перелік вузьких місць з оцінкою частоти та ціни збою.
- Схема перевірок. Визначаємо, що перевіряємо на етапі плану (склад ресурсів, зв'язки, значення атрибутів), а що — лише на розгорнутому середовищі: доступність сервісів, права доступу, ідемпотентність повторного застосування.
- Налаштування полігона. Збираємо ізольований проєкт з тестовими обліковими записами, обмеженням за часом життя й автоматичним прибиранням ресурсів — середовище не накопичує сміття й не заважає сусіднім командам.
- Набір перевірок. Terratest закриває сценарії «підняли — перевірили — знесли», kitchen-terraform — звірку фактичного стану з очікуваним. Набір розбитий за рівнями: швидкий контур, інтеграційний, наскрізний.
- Підключення до конвеєра збірки. Швидкі перевірки йдуть на кожен коміт, повний полігон — на релізні гілки. Перевірки запускаються паралельно в окремих проєктах, а результат блокує застосування змін при падінні.
- Розбір хибних спрацьовувань. Нестабільні перевірки лікуємо причиною — гонками, спільними ресурсами, занадто короткими таймаутами, а не вимкненням. Тримаємо правило: вимкнена перевірка повертається того ж дня.
- Передача. Віддаємо регламент супроводу, опис рівнів перевірок та інструкцію з додавання нового модуля — команда розширює набір без нас.
На виході кожна зміна проходить перевірку за хвилини, а не після викату в робоче середовище. Обговоріть задачу — повернемося з оцінкою та планом.
Артефакти впровадження: конфігурації, схеми, регламенти
Робота вважається зданою не за фактом успішного запуску, а за комплектом артефактів, з яким ваша команда далі працює без нас.
Усе, що ми проєктуємо, залишається у вашому репозиторії та вашій системі контролю версій — з історією змін і можливістю відкату на будь-яку попередню ревізію.
- Модулі опису інфраструктури — параметризовані блоки зі змінними та значеннями за замовчуванням: середовища піднімаються з одного набору, відмінності задаються значеннями, а не копіями конфігурацій.
- Комплект перевірок на Terratest — набір сценаріїв, який до застосування змін розгортає контур, перевіряє зв'язки між ресурсами й видаляє його за собою; плюс статичні перевірки формату та коректності посилань.
- Конфігурація полігона — ізольований тестовий контур, де перевірки проганяються цілком до продакшену, з окремими правами й без доступу до робочих даних.
- Схема ролей і доступів — розмежування прав доступу за ролями: хто вносить зміни, хто погоджує, у кого лише читання стану; застосування змін іде від окремого облікового запису.
- Документація інфраструктури — карта ресурсів і залежностей, опис змінних, точок розширення та того, які перевірки покривають яку ділянку.
- Регламент супроводу — порядок внесення змін: обов'язкові перевірки, вимоги до рев'ю, умови, за яких зміна не пропускається в робоче середовище.
- Інструкція з відкату — покроковий сценарій повернення до попереднього стану із зазначенням, що перевіряється після відкату.
Комплект передаємо з розбором на вашій стороні: показуємо, як запустити перевірки, додати нову та розширити модуль під задачу, якої зараз немає.
Кейс: автоматичні перевірки до застосування змін
Замовник — платформна команда з тридцятьма середовищами та спільною гілкою модулів.
Перевіркою змін служив ручний перегляд плану: три зміни з десяти доходили до робочого середовища й відкочувалися, а помилка рівня «видалено ресурс зі стану» могла жити в конфігурації тижнями, поки її не знаходив черговий запуск.
Що зробили
На кожен модуль з'явилися тести на Terratest: вони піднімають реальну інфраструктуру в ізольованому проєкті, застосовують конфігурацію, перевіряють фактичні властивості створених об'єктів і видаляють усе за собою.
Для машин додали kitchen-terraform — він перевіряє не лише застосування, а й стан усередині: запущені служби, права, шляхи, доступність портів.
План став обов'язковим кроком із контролем очікувань: число створюваних і видалюваних об'єктів звіряється з еталоном, а незаплановане видалення зупиняє процес перевірки до розбору інженером.
Що стало
Частка змін, що дійшли до робочого середовища й були відкочені, знизилася з 30% до нуля за квартал. Перевірка, яка займала два дні ручної роботи, вкладається в 25 хвилин і йде паралельно за середовищами.
Клас відмов «конфлікт типів і видалення зайнятих ресурсів» закрито повністю: тест на повторне застосування та подальше видалення обов'язковий для кожного модуля, і реліз без нього не збирається.
Окремий ефект — передбачуваність розбору: інженер отримує лог із конкретною невідповідністю, а не набір здогадок. Середній час від виявлення проблеми до виправлення скоротився вчетверо, бо середовище для відтворення піднімається тестом, а не руками.
Що робити, якщо частина інфраструктури описана вручну?
Ручна інфраструктура з'являється майже однаково: терміновий реліз, ресурс підняли в консолі провайдера, «тимчасове» рішення живе місяцями. Зносити й перестворювати таке за кодом не можна — на цих об'єктах уже дані та трафік.
Перший крок тут не переписування, а заведення наявних ресурсів в опис стану, щоб код і реальність зійшлися без простою.
Інвентаризація ресурсів: збираємо все, що реально існує, через інтерфейси провайдерів, звіряємо з конфігурацією та розмічаємо — під управлінням, поза управлінням, дубльоване. Окремо фіксуємо зв'язки між об'єктами: мережа, правила доступу, прив'язки томів.
Порядок перенесення задають саме ці залежності, інакше першим же перенесенням можна порвати маршрут до сервісу.
Поетапне перенесення йде по одному контуру або сервісу за раз, і критерій готовності етапу простий — порожній план змін: код описує рівно те, що є, і не збирається нічого видаляти. Для ресурсів з даними спочатку забороняємо перестворення, і лише потім правимо описи.
Перевірки підключаємо до наступного етапу: Terratest проганяє план і застосування на ізольованому середовищі та підтверджує, що мережа, права доступу й балансувальник збираються в потрібній конфігурації.
Стан тримаємо у віддаленому сховищі з блокуванням і версіями — відкат до попереднього знімка займає хвилини.
Підсумок: спочатку інвентаризація, потім по одному контуру з порожнім планом, і лише після цього — регламент, що відсікає ручні правки. Опишіть, що у вас створено в обхід описів, — повернемося з оцінкою та порядком етапів.
Часті технічні питання про перевірку інфраструктури
Інженерні сумніви щодо перевірки інфраструктури зазвичай зводяться до чотирьох тем: наскільки перевірки гальмують викат, де зберігати секрети, чи можна запускати набір локально та хто підтримує його в робочому стані.
Нижче — короткі відповіді, які ми розбираємо до старту, щоб не з'ясовувати це в середині впровадження.
Перевірки загальмують викат?
Terratest розгортає реальне середовище в ізольованому проєкті, а прогін розбитий за модулями й іде паралельно. На кожен коміт запускаються лише задіяні модулі — це хвилини, а не години. Довгі сценарії з повним розгортанням ідуть у нічний прогін і не блокують випуск.
Як бути із секретами в перевірках?
Секрети не потрапляють ні в код, ні в описи ресурсів: значення підтягуються зі змінних середовища та сховища секретів у момент прогону. У журналах вони маскуються.
У репозиторії залишаються лише імена змінних і приклади фіктивних значень — набір можна показувати й передавати без ризику витоку.
Чи можна запускати перевірки локально?
Так, якщо в інженера є доступ до тестового акаунта — набір запускається з робочої машини тією ж командою, що й на сервері перевірок. Там, де доступ видавати небажано, той самий прогін іде в контейнері. Це знімає чергу й дозволяє налагоджувати модуль одразу після правки.
Хто підтримує набір перевірок?
Набір живе разом із модулями: зміна ресурсу та правка тесту йдуть одним комітом, інакше перевірка розходиться з реальністю. Раз на квартал ми робимо ревізію — прибираємо дублі та застарілі сценарії, щоб набір не перетворювався на гальмо для викату.
Обговоримо задачу: як проходить перший розбір
Перший розбір інфраструктури — це не знайомство й не розмова про технології, а робота з артефактами. Ми просимо доступ до репозиторіїв з описом інфраструктури, до журналів прогонів і до переліку середовищ, щоб бачити фактичний стан, а не переказ.
На виході ви отримуєте карту, перелік ризиків та оцінку й план робіт за етапами — рішення щодо кожного етапу залишається за вами.
Що ми приносимо й розбираємо на першій зустрічі:
- Карту репозиторіїв і модулів: де описано стан, що перевикористовується, де дублювання та розбіжності.
- Перелік середовищ і відмінностей між ними — що налаштовано руками, а що описано кодом і відтворюється.
- Інвентаризацію перевірок: які вже є, які шляхи змін не покриті та де помилка дійде до робочого контуру.
- Розбір тестового контуру на Terratest: як перевіряється застосування конфігурацій, скільки йде прогін, що заважає запускати його на кожну зміну.
- Схему доставки змін і точок відмови: де процес зупиняється, де потрібен ручний крок і чому.
- Ризики відкату: де немає резервних копій стану, які зміни необоротні й як це обходиться.
- Оцінку й план робіт: етапи, критерії готовності кожного, склад команди та порядок приймання результату.
Опишіть задачу — повернемося з оцінкою та планом і назвемо термін першого розбору. Якщо за його підсумками вам достатньо власних сил, ми передамо матеріали у вашому форматі й не будемо пропонувати зайві етапи.
