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;
• как инфраструктура живёт сейчас — ручные операции, скрипты, экспорт из портала;
• роли и права: кто меняет окружения, кто согласует выкат;
• требования к согласованию изменений и допустимые окна для работ;
• состав сервисов, которые переводим в код в первую очередь;
• ограничения: политика безопасности, обязательное тегирование, требования аудита.

Первый разговор ведём с инженером, который будет делать работу: разбираем схему, спорные места и то, что уже пробовали. По итогу приходим с планом внедрения по этапам — что делаем сначала, где риски и как откатываемся, — и с оценкой работ по каждому этапу. Опишите задачу в свободной форме: вернёмся с оценкой и планом, дальше решаете вы.