Чому ручні правки в консолі ламають Pulumi-інфраструктуру
Pulumi зберігає файл стану, де зафіксовано фактичне положення ресурсів, і порівнює його з описом у коді. Консоль про цей файл не знає: інженер вручну розширює диск, відкриває порт або перейменовує базу, а стан тихо йде вбік від коду.
Наступний запуск або відкочує цю правку, або приносить розходження в план змін — і обидва варіанти підривають довіру до процесу.
Так працює дрейф конфігурації: будь-яке втручання руками живе поза кодом і поза історією. Воно не проходить перевірку, не потрапляє в рев'ю і не відтворюється при перестворенні середовища. Через місяць уже ніхто не пам'ятає, навіщо з'явилося правило і чи можна зняти його без наслідків.
Далі розходяться середовища: тестовий контур після кількох таких правок перестає бути копією продуктивного, і різниця спливає на релізі, а не на перевірках. Відкат теж перестає працювати — попередню версію не розгорнути, бо фактичний стан уже ніхто не описував.
Перед кожним випуском інвентар доводиться збирати руками, звіряючи консоль з кодом і сподіваючись, що нічого не пропустили.
Закривається це управлінням інфраструктурою як кодом: зміни тільки через рев'ю та застосування з коду, імпорт наявних ресурсів, регулярна звірка фактичного стану з описаним.
Нижче — як ми вибудовуємо такий контур, щоб дрейф ловився до релізу, а середовище піднімалося з коду без ручного складання.
Вимірювані ефекти: швидкість викочування, відновлення середовищ, дрейф
Переведення інфраструктури в опис у коді на Pulumi змінює не лише спосіб правок, а й те, як часто команда наважується їх робити.
Коли стан контурів збирається з одного опису, а не відтворюється вручну, вартість зміни падає: правка проходить рев'ю як звичайний код, а не як операція в консолі хмари.
Що фіксуємо як вимірюваний результат:
- Швидкість викочування змін — типова зміна проходить шлях від коміту до застосування на всіх контурах за хвилини; ручні кроки по консолях із процесу зникають.
- Відтворюваність середовищ — тестовий і продуктивний контури розрізняються тільки параметрами: однакові мережеві правила, ролі доступу, версії образів.
- Відновлення середовища — середовище піднімається з опису з нуля, тому результат не залежить від того, чи пам'ятає хтось послідовність дій.
- Дрейф — розходження між описом і реальним станом видно на плановому прогоні; ручна правка або потрапляє в опис, або відкочується.
- Частота змін — дрібні правки перестають вимагати вікна обслуговування, відкат на попередній опис займає одну операцію.
Обмеження знімається не з інфраструктури, а з команди: інженери перестають боятися торкатися робочого контуру, бо в кожної зміни є перевірюваний опис і шлях назад. Далі показуємо, як такий контур заводять і що залишається в замовника після передачі.
Pulumi проти шаблонів провайдера і ручних правок
Вибір підходу до інфраструктури — це не про синтаксис, а про те, хто і чим платитиме за зміни далі. Нижче — чотири варіанти, між якими реально обирають команди.
Перший стенд найшвидше збирається руками, і на одному середовищі це терпимо. Коли середовищ три-чотири і вони відрізняються парою параметрів, підтримка перетворюється на ручну звірку: розходження спливає вже під час збою.
| Підхід | Коли підходить | Обмеження | Що тримати своїй команді |
|---|---|---|---|
| Правки в консолі провайдера | прототип, одне середовище | стан ніде не зафіксовано, повтор стенда — вручну | інструкції та звірку стендів |
| Шаблони провайдера | типові ресурси без складної логіки | немає циклів і розгалужень, блоки копіюються | гілки шаблону під кожне середовище |
| Декларативна мова з файлом стану | єдиний зліпок інфраструктури, багато провайдерів | потрібен свій шар абстракцій і знання мови опису | модулі та порядок застосування змін |
| Код загальною мовою | команда пише на Python, TypeScript або Go, логіка важлива | код потребує тестів, перевірки та правил іменування | бібліотеки модулів і тести |
Загальна мова прибирає головний біль шаблонів: параметризація робиться функціями та циклами замість копіювання блоків, а декларативний опис ресурсів і їхнього стану зберігається — на цьому побудовано Pulumi. Підхід обирають за складом команди та складністю логіки, а не за модністю інструмента.
Як ми впроваджуємо управління інфраструктурою з коду
Керована інфраструктура починається не з коду, а з чесної інвентаризації: поки не виписано кожен ресурс із залежностями та власником, будь-який опис середовища відтворює накопичений дрейф. Тому порядок етапів у нас фіксований — кожен наступний спирається на результат попереднього.
- Інвентаризація ресурсів — обходимо акаунти й проєкти, збираємо реальні сутності, їхні зв'язки, теги та відповідальних. На виході — реєстр, з яким звіряємо кожну наступну зміну.
- Схема ресурсів і залежностей — розкладаємо реєстр за шарами: мережа, дані, обчислення, доступи. Визначаємо порядок створення, щоб зв'язки не перетворювалися на замкнені цикли.
- Опис середовищ — розділяємо середовища параметрами та окремими наборами значень, а не копіями конфігурацій. Шаблон один, відмінності середовищ задаються змінними, тому середовище піднімається відтворювано.
- Налаштування стану та секретів — стан виносимо в спільне сховище з блокуванням, щоб паралельні запуски не перетирали чужі зміни; секрети — у шифроване сховище, у репозиторії залишаються тільки посилання на них.
- Перевірка плану змін — кожна правка спершу показує, що буде створено, змінено та видалено. Видалення ресурсів із даними допускається тільки після явного рев'ю та підтвердження.
- Передача команді — регламент рев'ю, інструкція з локального запуску, розмежування доступів і порядок відкату до попереднього стану.
Роботу на Pulumi ми ведемо в цій самій послідовності — мову опису обирають під команду замовника. Критерій готовності один: середовище розгортається з нуля однією командою за хвилини, а не за дні, і результат збігається в розробника, тестувальника та в продуктивному середовищі.
Артефакти та регламенти: опис, стан, доступи
Передаємо ми не набір скриптів, а комплект, за яким команда замовника веде інфраструктуру сама. Кожен артефакт закриває свій клас питань: що розгорнуто, хто і як може це змінювати, як повернути попередній стан, якщо зміна виявилася невдалою.
Усе лежить у репозиторії замовника і версіонується разом із кодом — без усних домовленостей і «знання в голові одного інженера».
- Структура опису ресурсів. Єдиний шаблон на кожен стек: призначення, власник, середовище, зовнішні залежності. Новий інженер розуміє склад з опису, не читаючи всю конфігурацію цілком.
- Схема ресурсів. Карта зв'язків між компонентами: що від чого залежить, де спільні мережі та сховища, що видалиться разом із батьківським ресурсом.
- Політики доступу. Розмежування ролей на читання, попередній план і застосування; окремі права на тестовий і робочий контури; ручні правки в панелі хмари закриті.
- Управління секретами. Ключі та паролі не зберігаються в репозиторії — тільки посилання на захищене сховище, видача за ролями та регламент ротації.
- Регламент змін. Будь-яка зміна йде через запит на злиття з обов'язковим переглядом плану до застосування: видно, що додасться, зміниться або буде видалено.
- Правила відкатів. Історія версій опису та порядок повернення до попереднього стану, включно з випадками, коли відкат потребує ручних кроків.
- Документація середовищ. Як підняти копію контуру для перевірки, які перевірки проганяються автоматично перед застосуванням.
Плюс коротка інструкція з локального запуску та оглядовий запис розбору — команда повторює типову зміну за нею, не звертаючись до нас.
Кейс: дрейф трьох середовищ до і після переведення в код
До: три контури, які жили своїм життям
Інфраструктура з трьох середовищ — розробки, передпродакшну і продакшну — росла разом із продуктом, але керувалася руками. Інженер заходив у панель хмарного провайдера, додавав правило балансувальника, піднімав базу, змінював ліміти — і фіксував це хіба що в листуванні.
За кілька місяців контури розійшлися: частина мережевих налаштувань і прав доступу відрізнялася, а відтворити продакшн у тестовому середовищі вже було неможливо.
Ціна розходження виявилася не косметичною. Інцидент у продакшні розбирали довше, бо причина виявлялася в ручній правці місячної давнини, а відновлення середовища після збою займало до шести годин. Випуск супроводжували понад сорок ручних операцій — і будь-яка з них могла поїхати не в той контур.
Після: один опис на всі три середовища
Інфраструктуру перенесли в код на Pulumi: топологію описано один раз, а відмінності контурів винесено в параметри — розмір вузлів, число реплік, рівень доступу.
Зміни проходять перевірку як звичайний код і залишаються в історії, тому питання «хто і коли змінив правило» закривається за хвилину, а нове середовище піднімається копією опису, без ручного складання з пам'яті.
Через два місяці експлуатації в новому режимі картина така: час відновлення середовища після збою скоротився з шести годин до 25 хвилин, ручних операцій при випуску залишилося три замість сорока з гаком, а розходження між контурами виявляє автоматична звірка протягом години замість розбору на око. Відкат до попереднього стану — одна операція з передбачуваним результатом, без «поверни як було».
Що робити, якщо інфраструктура вже розгорнута поза Pulumi
Якщо інфраструктура вже розгорнута — вручну або іншим інструментом — перестворювати її не потрібно: Pulumi приймає наявні об'єкти під управління. Імпорт ресурсів в опис прив'язує реальний об'єкт до коду: ідентифікатор потрапляє у файл стану, сам об'єкт залишається на місці.
Тонкість у тому, що переноситься лише посилання — фактичні параметри потрібно описати в коді точно такими, якими вони є зараз.
Інакше перший же прогін спробує наздогнати опис: змінить налаштування, перестворить ресурс або завалить його. Тому перенесення наявних ресурсів починається зі зняття фактичного стану — воно потрапляє в код без правок, а зміни робляться окремим кроком і окремим прогоном.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повний імпорт | Один контур, прості залежності, є актуальна схема ресурсів | Тривала інвентаризація; помилка в параметрі призводить до перестворення об'єкта |
| Поступове перенесення за контурами | Кілька середовищ, критичний прод, важливий контрольований темп | Довше живуть два джерела правди, потрібен регламент володіння |
| Паралельне ведення | Велика успадкована частина, яку не можна зупиняти | Ризик конфлікту за один і той самий об'єкт, потрібне жорстке розділення |
Стан опису — точка правди, і в кожного об'єкта має бути один власник: якщо два описи посилаються на той самий ресурс, вони починають перетягувати його налаштування.
Паралельне ведення виправдане лише як тимчасовий захід — з розділенням за типами ресурсів і строком, після якого залишається один опис.
Технічні сумніви: стан, секрети, відкат
Перед тим як узгоджувати роботи, технічні замовники ставлять ті самі питання: де лежить стан інфраструктури, що станеться при втраті доступу, як розділено середовища і наскільки безпечно відкочувати зміни. Нижче — короткі відповіді, які зазвичай знімають сумніви на етапі оцінки.
Стан — не деталь реалізації, а частина контуру безпеки. Тому його розміщення, шифрування секретів і права команди ми проєктуємо разом із самою інфраструктурою, а не «доналаштовуємо» після першого інциденту.
Де зберігається стан і що буде при втраті доступу?
Стан виносимо у віддалений бекенд із блокуваннями — паралельні застосування не перетирають одне одного. Версії снапшотів зберігаються, тому доступ можна відновити за попередньою ревізією, а не збирати стан заново.
Як ізолюються середовища?
Кожне середовище — окремий стек зі своїм набором параметрів і своїм хмарним акаунтом або проєктом. Крос-посилання між тестовим і промисловим контуром заборонені, тому помилка в тесті фізично не може змінити продуктив.
Що робити, якщо зміна зламала інфраструктуру?
Кожне застосування пише історію. Відкат — це повторний запуск попередньої ревізії опису або повернення до ранішого снапшоту стану з подальшою звіркою з реальними ресурсами. Цільовий час відновлення — хвилини, а не години ручних правок.
Як розмежовуються доступи команди?
Права видаємо ролями: читання стану, планування змін і застосування — різні рівні. Секрети розшифровуються тільки тими, у кого є ключ, а всі запуски потрапляють у журнал з автором і часом.
Хто супроводжує опис після здачі?
Опис залишається у вашому репозиторії з документацією щодо структури стеків і порядку випуску. Далі його веде ваша команда — або ми, за окремою угодою про супровід.
Обговоримо задачу і повернемося з оцінкою та планом
Для старту достатньо описати, як інфраструктура живе зараз: що вже заведено кодом, що налаштовувалося руками через панель управління, які середовища обслуговуються і в кого є до них доступ.
Ділянки, які тримаються на текстових інструкціях і пам'яті одного інженера, теж варто назвати — ми закладаємо їх у план перенесення окремо, а не знаходимо в середині робіт.
- оцінка обсягу за етапами: скільки роботи в кожному і де зосереджені ризики;
- план робіт із порядком старту: з чого починаємо, що йде паралельно, коли з'явиться перше середовище, підняте кодом;
- схема розділення середовищ і правила просування змін між ними;
- перелік доступів і вихідних даних, які потрібні від вас для старту;
- критерії готовності на кожному етапі — за ними ви приймаєте результат;
- формат звітності: що і як часто ви бачите в процесі робіт.
Керівник напряму, чию інфраструктуру ми переводили на Pulumi, описує результат так: «Правка середовища перестала бути подією з ручною перевіркою — тепер це звичайна зміна, яка проходить перевірку і відкочується однією командою».
Опишіть задачу у вільній формі: що розгорнуто, що болить, які строки тиснуть. Ми повернемося з оцінкою обсягу та планом робіт — з порядком старту і тим, що знадобиться від вашої команди.
