Infrastructure as Code (IaC) з використанням Azure Bicep

Azure Bicep: де ручне налаштування інфраструктури дає збої

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

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

Через кілька тижнів ніхто вже не може точно сказати, чим середовища відрізняються — а отже, не можна передбачити й поведінку після релізу.

Друга точка відмови — неявні залежності. Порядок створення ресурсів тримається в інструкції або в пам'яті: мережа, підмережа, інтерфейс, віртуальна машина.

Варто зробити крок не в тому порядку — розгортання падає на середині, залишаючи наполовину зібране середовище, яке доводиться розбирати вручну.

Третя проблема — невідтворювані правки: хтось виправив параметр прямо в консолі, зміна ніде не зафіксована, і наступне розгортання або затирає її, або створює дубль ресурсу. Помилки конфігурації за такої схеми виявляються вже в момент відмови, а не на етапі перевірки.

Bicep усуває саму причину: опис інфраструктури стає файлом у системі контролю версій, який проходить рев'ю нарівні з кодом застосунку.

Порядок створення ресурсів платформа виводить із залежностей сама, розходження середовищ видно порядково як різницю в шаблоні, а повторне розгортання в порожній підписці дає те саме середовище. Відтворюваність розгортання перестає залежати від того, хто саме і в якому порядку натискав кнопки.

Розбираємо нижче, як це переноситься на живу інфраструктуру: від структури модулів до безпечного переведення вже працюючих середовищ під опис у коді.

Що змінюється після переходу на описи інфраструктури

Поки середовища збираються вручну через портал, між контурами накопичується розходження: на тестовому увімкнено параметр, якого немає на промисловому, правило брандмауера додано лише в одному місці, сертифікат замінено на одному вузлі з трьох.

До інциденту це непомітно, а розбір щоразу починається з питання «хто і коли це змінив» — у журналі порталу відповіді зазвичай немає.

Описи інфраструктури на Bicep прибирають саму категорію ручних правок.

Середовище збирається з файлів повністю, а новий майданчик — тестовий контур, стенд для перевірки гіпотези — піднімається за десятки хвилин замість днів: параметрами відрізняються розміри вузлів і кількість екземплярів, а не склад ресурсів.

Єдиний стандарт середовищ тримається на спільній базі описів і окремому наборі параметрів на кожне оточення.

Різниця між контурами видна як різниця двох невеликих файлів і проходить той самий розбір, що й код застосунку: зміна потрапляє в історію, перевіряється до застосування і відкочується поверненням до попередньої ревізії опису.

Звідси падіння частки відкатів через людський фактор — типові помилки ручного складання просто перестають відтворюватися.

Час відновлення після збою змінює природу: втрачене середовище не збирають із пам'яті, а розгортають заново тим самим описом.

Простій обмежений одним запуском розгортання і не розтягується на погодження та ручні операції — поряд піднімається ідентична копія, на яку перемикається трафік.

Azure Bicep та альтернативні підходи: порівняння

Опис інфраструктури кодом починається з вибору мови: від нього залежить, як рев'юються зміни, наскільки перевикористовуються готові модулі та скільки коштує супровід шаблонів, коли ресурсів стає сотні.

Нижче — варіанти, між якими реально вибирають у проєктах на Azure, з їхніми обмеженнями та ціною підтримки.

Що це дає на практиці

Bicep залишається декларативним: файл збирається в ARM-шаблон, а перевірка плану перед застосуванням показує, які ресурси зміняться або видаляться.

Модулі виносяться в спільний реєстр і версіонуються, тому оточення піднімаються одним набором з різними параметрами — розходження між стендами перестає накопичуватися.

Обмеження підходу — прив'язка до Azure: гібридні сценарії збираються з двох інструментів, і це закладається в структуру репозиторіїв заздалегідь. Супровід шаблонів — окрема робота: перевірки в конвеєрі, рев'ю змін, оновлення модулів у міру виходу нових можливостей платформи.

Як ми впроваджуємо описи інфраструктури: етапи робіт

Перенесення інфраструктури в описи на Azure Bicep починається не з коду, а з розбору того, що реально працює в підписці. Інакше шаблони відтворюють уявлення про систему, а не саму систему, і розходження спливають у момент відкату або масштабування.

1. Інвентаризація ресурсів. Збираємо фактичний склад підписки та груп ресурсів, звіряємо з документацією і окремо позначаємо все, що налаштовано вручну: самі ресурси, ролі доступу, зв'язки між сервісами.
2. Схема залежностей. Фіксуємо, що від чого залежить і в якому порядку створюється — мережі, підмережі, правила доступу, сховища, застосунки. Схема показує, які зв'язки описуємо явно, а які передаємо параметрами.
3. Модулі інфраструктури. Однотипні блоки виносимо в модулі для перевикористання з версіями та параметрами за середовищем, секрети виводимо в захищене сховище і залишаємо в шаблонах лише посиланнями.
4. Перевірка змін. Кожну зміну проганяємо через попередній розрахунок: видно, що буде створено, змінено та видалено. Видалення розбираємо окремо — саме там найчастіше губляться дані та доступи.
5. Ізольоване середовище. План застосовуємо на копії контуру: перевіряємо розгортання з нуля, повторний прогін без змін і відкат на попередній стан.
6. Передача. Віддаємо репозиторій з модулями, схему залежностей і порядок випуску змін; перші випуски проводимо разом з вашою командою.

Такий порядок дає відтворюваний результат: будь-яке середовище можна перезібрати з нуля і звірити з тим, що описано в репозиторії, а не з поточним станом порталу.

Конфігурації, схеми та регламенти, які ви отримуєте

Комплект розрахований на те, що супровід залишається у вашої команди: інфраструктура не перетворюється на «чорну скриньку», а передається разом з описами та регламентами.

Усе лежить у вашому репозиторії і проходить перевірку в системі контролю версій — історія правок і авторство зберігаються.

• Комплект описів інфраструктури — модулі Azure Bicep за шарами: мережа, сховища, бази, застосунки. Один код з різними наборами параметрів розгортає стенд розробки, передпродуктивний і продуктивний контури.
• Схема оточень — карта підписок, груп ресурсів і зв'язків між сервісами: що де живе, чим оточення відрізняються, які дані між ними перетікають.
• Правила доступу — матриця ролей і областей дії: що інженер змінює напряму, що потребує погодження, що закрито повністю; окремо — права служб розгортання.
• Регламент змін — шлях від гілки до продуктивного контуру: хто готує опис, як проходить перевірка, як виглядає попередній план змін і як виконується відкат.
• Інструкції з типових операцій — розгорнути оточення з нуля, додати ресурс, оновити компонент, відтворити збій на копії продуктивного контуру.
• Захист від розходжень — перевірки, які не дають ручним правкам у панелі керування розійтися з описом.
• Перелік зовнішніх залежностей — доменні імена, сертифікати, секрети, мережеві зв'язки: де зберігаються і як ротуються.

Пакет передаємо з розбором на дзвінку: ваші інженери проходять кожен пункт разом з нами і далі ведуть інфраструктуру самостійно.

Кейс: переведення середовищ на описи інфраструктури

До переходу на описи інфраструктури середовища збирали вручну: тестовий контур копіювали з продуктивного і правили параметри «на місці». Розходження накопичувалися — стенди, задумані як однакові, відрізнялися налаштуваннями мереж, правилами доступу та версіями залежностей.

Причину збою шукали в застосунку, хоча ламалося оточення, а на підняття нового стенда йшло 2-3 дні ручних операцій.

Три контури — розробка, передпродуктивний і продуктивний — перевели на єдиний набір шаблонів на Azure Bicep. Опис розбито на модулі: мережа, сховище, бази, застосунок.

Контур задається файлом параметрів, тому відмінність середовищ видно в одному файлі, а не розмазана по сотнях ручних правок.

Метрики до і після

• Підняття нового стенда: було 2-3 дні ручних операцій з очікуванням погоджень — стало 40-50 хвилин від запуску.
• Інциденти через конфігурацію: близько 5-6 за квартал — жодного нового за пів року; розходження виявляє перевірка описів до застосування.
• Відкат до попереднього стану: було відновлення з резервної копії та ручна звірка за кілька годин — стало повторне застосування попереднього опису за 10-15 хвилин.

Окремо закрили дрейф конфігурації: планова перевірка порівнює фактичний стан середовища з описом і показує розходження, нічого не видаляючи автоматично. Зміни проходять ті самі етапи, що й код — перегляд різниці версій, прогін в ізольованому контурі, і лише потім продуктив. Нове середовище тепер не «приблизно як продуктивне», а його точна копія за конфігурацією.

Чим декларативний опис відрізняється від ручних скриптів?

Різниця проявляється в момент, коли інфраструктуру потрібно не створити з нуля, а змінити. Імперативний скрипт — це послідовність команд: створити групу ресурсів, потім мережу, потім вузли. Він описує процес, а не результат, і тому не знає, що частина ресурсів уже існує.

Декларативний опис задає цільовий стан: перелічуємо ресурси, їхні зв'язки та параметри, а приведення до цього стану бере на себе інструмент. Опис на Azure Bicep перевіряється під час збирання і на повторному запуску не створює дублів — той самий файл дає той самий результат.

Читабельність конфігурації вирішує, скільки коштує наступна зміна. Файл з оголошеними ресурсами читається згори вниз і рев'юїться порядково, а скрипт на сотні команд доводиться спочатку відновити в голові — особливо якщо писав його інший інженер.

Один підхід не витісняє інший. Скрипти залишаються зручними для разових дій: міграція даних, разові перевірки, аварійні роботи. Усе, що має існувати постійно, описується декларативно — інакше стан інфраструктури зберігається лише в історії запусків.

Часті технічні сумніви перед стартом проєкту

Розбираємо сумніви до старту — зазвичай вони стосуються часткової міграції, перенесення між підписками та підтримки після передачі. Нижче відповіді на те, що найчастіше гальмує рішення.

Наскільки складно перенести конфігурацію між підписками?

Опис параметризується: ідентифікатори оточень виносяться в окремі набори параметрів, тому зміна підписки — це підстановка іншого набору і перевірка залежностей, а не переписування шаблонів. Оточення розробки, тестування і промислове отримують ту саму логіку.

Як переконатися, що зміна нічого не зламає?

Перед застосуванням запускається попередній перегляд: видно, які ресурси створюються, змінюються і видаляються. Зміни проходять перевірку в системі контролю версій, застосування йде погодженими блоками — видалення ресурсу видно заздалегідь і потребує підтвердження.

Що відбувається після передачі проєкту?

Передаємо опис інфраструктури, схеми залежностей між ресурсами, набори параметрів та інструкції з типових операцій. Далі — супровід: розбір інцидентів, доопрацювання модулів, навчання вашої команди.

Терміни впровадження залежать від обсягу: пілот на одному оточенні займає тижні, розширення на решту йде слідом.

Обговоримо задачу і повернемося з оцінкою та планом

Щоб оцінка робіт спиралася на факти, а не на здогади, для старту достатньо вхідних даних — детальний аудит на цьому етапі не потрібен. Зберемо їх в одному місці: перелік підписок і оточень, поточний стан інфраструктури, правила доступу. Цього достатньо, щоб побачити обсяг робіт і порядок переведення ресурсів в опис кодом.

• підписки, групи ресурсів і межі периметра: де dev, stage і prod;
• як інфраструктура живе зараз — ручні операції, скрипти, експорт з порталу;
• ролі та права: хто змінює оточення, хто погоджує викат;
• вимоги до погодження змін і допустимі вікна для робіт;
• склад сервісів, які переводимо в код у першу чергу;
• обмеження: політика безпеки, обов'язкове тегування, вимоги аудиту.

Першу розмову ведемо з інженером, який буде робити роботу: розбираємо схему, спірні місця і те, що вже пробували. За підсумком приходимо з планом впровадження за етапами — що робимо спочатку, де ризики і як відкочуємося, — і з оцінкою робіт за кожним етапом. Опишіть задачу у вільній формі: повернемося з оцінкою та планом, далі вирішуєте ви.