AWS CloudFormation: де ручне налаштування хмари ламається
Ручне налаштування хмари ламається не на першому запуску, а на третьому-четвертому зміненні. Інженер додає правило в security group, піднімає інстанс, навішує теги — і повторює це в dev, stage та prod із пам'яті.
За тиждень середовища розходяться: у stage увімкнено логування, у prod — ні, версія образу на одному стенді оновлена, на іншому залишилася попередня. Яка конфігурація була робочою на момент інциденту — не знає ніхто.
Розходження конфігурації не видно до першого серйозного збою. Коли падає прод, відновлення перетворюється на археологію: частина налаштувань осіла в нотатках, частина — у голові інженера, який саме у відпустці.
Час відновлення зростає не тому, що команда працює повільно, а тому що середовище не можна відтворити з нуля.
Інфраструктура як код знімає це на рівні моделі: опис стенда живе в шаблонах, зміни проходять перевірку й потрапляють у систему контролю версій, а не в консоль.
Автоматизація AWS через CloudFormation робить кожен стенд результатом застосування одного й того ж опису — від мереж і балансувальників до прав доступу. Відтворюваність середовищ перестає залежати від того, хто саме збирав стенд і в якому порядку натискав кнопки.
Розбираємо, як це закривається на практиці: де проходять межі між шаблонами і що робити з ресурсами, які вже налаштовані вручну.
Що змінюється після переходу на шаблони інфраструктури
Перший контур, зібраний за описом, задає точку відліку: якщо раніше середовище піднімали руками кілька днів і кожен стенд виходив трохи іншим, то тепер розгортання займає 15-20 хвилин.
У стенді відтворюються мережа, права, групи безпеки та параметри сервісів — без «забутих» налаштувань із чек-листа.
Далі змінюється сама природа відкатів. Розходження налаштувань між стендами — найчастіше джерело «локально працює, на проді ні» — зникає як клас: частка відкатів із цієї причини падає з половини випусків до поодиноких випадків, бо всі середовища збираються з єдиного шаблону.
За кілька тижнів помітно скорочується час відновлення. Аварійний контур не лагодять вручну, а перестворюють з опису — десятки хвилин замість годин, проведених у правці конфігурацій під навантаженням. Відкат до попередньої версії середовища стає такою ж штатною операцією, як випуск.
Вартість простою перестає бути невідомою величиною. Вікно недоступності більше не розтягується на діагностику: воно обмежене часом застосування шаблону, а цей час відомий заздалегідь і його можна закладати в угоду про рівень сервісу.
На дистанції місяців ефект накопичується: зміни перевіряються до застосування, стенди піднімаються під кожну задачу і так само зносяться, середовища залишаються ідентичними.
AWS CloudFormation тут працює не як інструмент заради інструменту, а як виконуваний опис інфраструктури, який лежить у репозиторії поруч із кодом сервісу.
Способи опису інфраструктури: порівняння підходів
Декларативні шаблони описують бажаний стан, а інструмент сам приводить до нього акаунт — це прибирає розходження між документацією та реальністю. Але вибір конкретного підходу визначає, скільки інженерних годин іде на супровід щомісяця. Нижче — варіанти, між якими справді обирають, та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Шаблони CloudFormation (YAML/JSON) | Уся інфраструктура в одній хмарі, потрібен нативний відкат стеку та зв'язка з ролями доступу | Громіздкий синтаксис на великих описах, відкат іде цілком по стеку |
| Модулі мовою програмування (CDK, Pulumi) | Команда пише код і хоче перевикористовувані модулі, цикли та перевірку типів | З'являється крок збірки, потрібна дисципліна версій бібліотек |
| Описи на HCL (Terraform) | В одному контурі кілька хмар і сервісів різних постачальників | Окреме сховище стану, блокування узгоджуються вручну |
| Скрипти налаштування (Ansible) | Приведення до єдиного вигляду вже працюючих машин, разові операції | Не зберігають стан, повторний запуск дає різний результат |
Модулі інфраструктури знімають головний біль: типова мережа, ролі доступу та логування описуються один раз і підключаються параметрами.
Замість копії шаблону на кожне середовище з'являється один модуль і файл значень — правка в ньому змінює всі середовища одразу, а не тричі вручну.
Обмеження автоматизації варто визнати заздалегідь. Ресурси, створені застосунками, дані у сховищах і правки через консоль залишаються поза описом — тому в процес закладають регулярне порівняння фактичного стану з шаблоном і правило, що стек залишається єдиним джерелом правди. Інакше вже перша ручна зміна обнуляє всю вигоду від автоматизації.
Порядок впровадження: від аудиту до передачі регламентів
Порядок робіт тут важливіший за швидкість: шаблон, зібраний без інвентаризації, описує не ту інфраструктуру, а виведення його одразу в продуктив перетворює помилку на простій. Тому етапи впровадження йдуть послідовно, і кожен наступний спирається на результат попереднього.
-
Аудит інфраструктури. Проходимо по акаунтах і регіонах, фіксуємо фактичні ресурси, зв'язки між ними та зміни, зроблені руками в обхід описів. На виході — інвентарна відомість і перелік розходжень із документацією.
-
Схема залежностей. Розкладаємо ресурси по стеках: мережа, обчислення, сховища, доступи. Визначаємо порядок створення і те, що не можна змінювати без простою, — це задає межі шаблонів CloudFormation.
-
Збірка шаблонів. Описуємо ресурси декларативно, параметризуємо відмінності середовищ і виносимо секрети окремо від описів. Повторювані блоки згортаємо в спільні фрагменти — правка робиться в одному місці.
-
Перевірка на стенді. Розгортаємо копію контуру в ізольованому середовищі та проганяємо повний цикл: створення з нуля, зміна, видалення. Розходження з очікуваним планом змін ловимо до продуктивного середовища.
-
Виведення в продуктив. Переводимо ресурси під управління описами поетапно, звіряючи стан після кожного кроку. Попередня конфігурація зберігається до підтвердження результату — відкат залишається можливим.
-
Передача регламентів. Віддаємо описи шаблонів, схему стеків, порядок правок і правила перевірки змін, інструкції з відкату. Команда замовника вносить зміни сама, без звернення до нас на кожному кроці.
Комплект шаблонів, схеми та регламенти передачі
Після впровадження в команди замовника залишається робочий репозиторій з описами інфраструктури, а не набір скриншотів із консолі.
Комплект розрахований на інженера, який не брав участі в роботах: за ним можна розгорнути середовище з нуля, побачити зв'язки між сервісами та безпечно провести зміну.
- Шаблони середовищ — описи CloudFormation для розробки, тестового та продуктивного контурів. Різняться параметрами, а не копіями коду: правка в одному місці не розходиться по трьох версіях.
- Схеми залежностей — порядок створення та видалення ресурсів, вкладені стеки, передача значень між ними. За схемою видно, що зачепить зміна конкретного ресурсу.
- Політики доступу — ролі для розгортання та для застосунків, межі прав, розділення ручних правок і змін через шаблон.
- Регламент змін — гілка, збірка, перевірка другим інженером, підтвердження для продуктивного контуру, порядок відкату на попередню версію.
- Документація — призначення параметрів, вихідні значення, інструкція з розгортання з нуля, відомі обмеження та обхідні рішення.
- Захисти від випадкового руйнування — заборона видалення стеку, політики на оновлення критичних ресурсів, регулярне звіряння фактичного стану з описом.
- Каталог перевикористовуваних фрагментів — типові блоки мережі, сховища та прав, які підключаються в нові сервіси замість копіювання.
Комплект передаємо з розбором на працюючій інфраструктурі та розміткою, де що лежить. Далі ваша команда вносить зміни сама.
Кейс: як скоротився час розгортання контуру
Контур для приймання та передпродакшену збирався вручну за інструкцією: мережі, балансувальник, бази, права доступу.
Повне розгортання займало 6–8 годин роботи двох інженерів, а розходження між середовищами випливали вже на тестуванні — частину змін відкочували зворотними правками прямо в консолі.
Ми описали інфраструктуру декларативно в шаблонах Amazon Web Services CloudFormation: окремий стек на кожне середовище, спільні параметри винесені в окремий шар, зміни проходять рев'ю до застосування. Відкат перестав бути ручною операцією — повернення до попереднього стеку займає один крок.
До і після
Розгортання контуру з нуля скоротилося з 6–8 годин до 20–25 хвилин, і запускає його один інженер, не чекаючи на решту. Частка відмов під час викатки знизилася приблизно втричі: середовище відтворюється один в один, бо зміни приходять з опису, а не з ручних правок.
Час відновлення після збою конфігурації впав із кількох годин до 10–15 хвилин — контур просто перезбирається.
Окремий ефект — нові середовища: тестовий контур під задачу піднімається за пів години замість тижня узгоджень і збірки. Шаблони та параметри стали спільним активом: команда додає середовища копіюванням шару, а не повторенням інструкції.
Чим AWS CloudFormation відрізняється від ручних сценаріїв?
Скрипт виконує послідовність команд: створити, налаштувати, підключити. Він не знає, що вже зроблено, тому повторний запуск або падає на наявному ресурсі, або створює дублікат.
AWS CloudFormation працює за іншою моделлю — шаблон описує бажаний стан, а не порядок дій, і система сама приводить інфраструктуру до цього опису.
Ключова відмінність — управління станом. Стек зберігає відомості про фактично створені ресурси, тому повторне застосування шаблону обчислює різницю між описом і реальністю та змінює лише її.
Один і той самий шаблон застосовується багаторазово з однаковим результатом, а точкова правка параметра не перезбирає все середовище заново.
Далі шаблон стає єдиним джерелом правди. Він лежить у системі контролю версій і проходить перевірку як код, тому з історії змін видно, хто, коли і навіщо змінив конкретний параметр.
Правки, внесені в консолі вручну, випливають як розходження з шаблоном, а не живуть в інфраструктурі роками як нікому не відома деталь.
Оновлення теж ідуть інакше: перед застосуванням видно, що буде створено, змінено або видалено, а в разі помилки стек повертається до попереднього стану.
Невдалий прогон не залишає половину середовища в невідомому вигляді — відновлення та розгортання нового середовища виконуються за одним сценарієм.
Технічні сумніви перед початком робіт
Сумніви перед стартом зазвичай технічні: що буде з працюючим контуром, як контролювати правки в обхід шаблонів і хто отримує доступ до продакшену.
Уже є працюючий контур — усе перезбирати?
Ні. Ресурси описуємо в шаблонах і підключаємо до наявних налаштувань без перестворення: сервіси продовжують працювати. Далі зміни йдуть лише через шаблон, а консоль залишається для читання стану.
Чи можна впроваджувати частинами?
Так, за шарами: мережа, дані, застосунки. Кожен шар — окремий стек із явними залежностями, тому автоматизація однієї ділянки не блокує решту та не вимагає зупиняти роботи.
Як відстежувати ручні правки?
Перевірка розходжень показує зміни, зроблені в обхід шаблону. Їх або повертають у код, або свідомо закріплюють — невідомих відхилень у контурі не залишається.
Як ділити права доступу?
Ролі прив'язані до стеків і середовищ. У прод зміни потрапляють лише через конвеєр із рев'ю; у розробників — тестовий контур і читання стану проду.
Що з відкатом змін?
Перед застосуванням показуємо план: що створюється, змінюється, видаляється. Відкат — повернення до попередньої версії шаблону, стан стеку приводиться до неї.
Обговоримо задачу та повернемося з планом впровадження
На першому розборі дивимося не на формулювання «потрібен код замість ручних правок», а на фактичний стан інфраструктури: що вже описано в шаблонах AWS CloudFormation, а що досі піднімається руками з консолі.
Уточнюємо кількість середовищ і облікових записів, розділення бойового та тестового контурів, схему доступу команди і те, як зміни зараз потрапляють у бойове середовище — ручною правкою чи через автоматизоване розгортання.
Окремо фіксуємо, що не можна чіпати без нагальної потреби: бази з даними, мережеві правила, прив'язки доменів.
Повертаємося з документом, а не з усними обіцянками: у ньому видно, з чого складається робота, скільки займає кожен етап і на якому кроці ви отримуєте проміжний результат.
- карта інфраструктури: які ресурси переходять під управління шаблонами, які залишаються поза кодом і чому;
- склад робіт за етапами — від підготовки описів до перенесення середовищ і налаштування розгортання;
- строки кожного етапу та точки, де ви бачите працюючий результат, а не звіт;
- порядок міграції з планом відкату до попереднього стану на кожному кроці;
- правила іменування ресурсів, розбиття на перевикористовувані блоки та зберігання параметрів;
- перелік перевірок, які проганяються до застосування змін до бойового контуру;
- критерії приймання: що вважається виконаним на кожному етапі та хто це підтверджує.
Опишіть задачу — кількості середовищ, поточного способу розгортання та обмежень щодо доступів достатньо, щоб ми повернулися з оцінкою та планом робіт.
