Добро пожаловать в очередной выпуск Microsoft Knowledge на Getas на M365FM. Я ваш ведущий, Мирку Питерс. Вы развертывали ресурсы Azure, просто нажимая на кнопки в портале. Все идет хорошо, пока не перестает работать. Затем нужно повторить процесс, но вы не можете вспомнить, что именно выбирали. Нужно передать задачу коллеге, а он не может повторить ваши действия. Контроль версий. Тут нечего комметить. Именно эту проблему мы сегодня и решим. К концу этого выпуска вы поймете, что такое инфраструктура, как код. Зачем нужен BISIP и как он делает развертывание в Azure проще и надежнее. Мы начнем с проблемы, затем перейдем к решению, а после – к практическому примеру, который вы сможете повторить. Берите кофе и давайте начнем. Проблема портала. Ловушка развертывания через клики кажется быстрой. Вы вошли, заполнили форму, нажали «Создать» и готово. Но что делать, когда нужно повторить это с теми же настройками, регионом и соглашением об именовании?

Вы должны помнить каждую деталь, которую выбрали, и именно здесь все начинает рушиться. Ручное развертывание ведет к несоответствиям, человеческим ошибкам и отсутствию аудита. Вот пример из жизни. Кто-то из вашей команды создает ресурс с немного другими настройками. Теперь у вас две среды, которые не совпадают друг с другом. Одна работает, другая нет – удача в выяснении причин. А еще есть проблема с документацией. Инфраструктура в виде документа Word или, что еще хуже, видео на YouTube, записанного полгода назад, когда портал выглядел совсем иначе. Функции перемещаются, меню меняются, появляются новые опции. Я общался с менеджером по продукту из команды Azure, и он сказал, что они выпускают новые функции дважды в день. Дважды в день. Ваш документ Word устаревает еще до того, как вы закончите его писать. Суть в следующем. Нажимать на кнопки удобно для обучения. Это не подходит для продакшена.

Пишите файл с описанием того, что хотите, а затем говорите Azure это создать. Что такое инфраструктура как код? Инфраструктура как код – это управление облачными настройками с помощью кода вместо кликов по веб-порталу. Вот основная идея. Вы пишете файл, описывающий инфраструктуру, храните его в репозитории, используете контроль версий, проверяете в пул рекист и запускаете снова завтра, чтобы получить тот же результат. Здесь есть ключевой термин – декларативность. Это значит, что вы описываете, что хотите получить, а не то, как это построить. Вы не говорите Azure, сначала создай группу ресурсов, затем добавь учетную запись хранения. А потом настрой сеть. Вместо этого вы говорите «Я хочу группу ресурсов с учетной записью хранения и сетью, настроенными вот так». А Azure сама определяет порядок действий. Результат называется и демпатентностью. Запустите код один раз или сто раз, вы получите один и тот же результат.

В этом вся сила. Представьте это как чертеж в противовес строительству вручную. Чертеж можно повторно использовать, передавать другим и проверять. Передайте его другому человеку, и он построит в точности то же самое. Сейчас для этого есть несколько инструментов. ARM-шаблоны, BISIP, Terraform, Pulumi. Все они реализуют одну и ту же концепцию по-разному. Это важное различие. Инфраструктура как код – это сама концепция. BISIP – лишь один из инструментов ее реализации. Но вот в чем дело. У Azure уже много лет есть язык для ИК, который называется ARM-шаблоны. И есть причина, по которой Microsoft создала новый. Проблема ARM-шаблонов. ARM-шаблоны – это оригинальный формат ИК для Azure. Это JSON-файлы, и у них много преимуществ. Полный охват всех ресурсов Azure и тот же движок развертывания, что используется внутри системы. Если вы можете создать что-то на портале, вы можете описать это в ARM-шаблоне.

Так в чем же проблема? JSON-файл хорош для машин, но ужасен для людей. Позвольте показать, что я имею в виду. Учетная запись хранения в ARM-шаблоне занимает около 20 строк кода. Та же учетная запись в BISIP – около 10 строк. JSON-версия примерно в два раза больше. И это лишь простой ресурс. Представьте полноценное развертывание с сетью, вычислениями, базами данных и правилами безопасности. ARM-шаблон превращается в сплошную стену текста. Типичные проблемы вполне предсказуемы. Пропущенные запятые, непарные скобки, громоздкая вложенность, из-за которой трудно понять, где заканчивается один ресурс и начинается другой. Вы тратите больше времени на борьбу с синтаксисом JSON, чем на описание инфраструктуры. А еще есть зависимости. В ARM вы должны вручную объявлять Dependison. Если ресурсу а нужно, чтобы сначала существовал ресурс, вы должны прописать это явно. Пропустите один, и развертывание не удастся.

Удачи в попытках понять, какой именно вы пропустили. Если вы хоть раз пытались написать 200-строчный JSON-файл вручную, вы знаете, это не весело. Совсем не весело. Кривая обучения довольно крутая. Новым членам команды трудно разобраться в ARM-шаблонах. Порог вхождения очень высок. И что происходит на практике? Во многих командах остается только один человек, знающий ARM-шаблоны. Этот человек становится единой точкой отказа. Только он может изменять развертывание, и только он может отлаживать его, если что-то сломается. Это нерационально. Microsoft услышала отзывы и создала BISIP, чтобы решить именно эти проблемы. Что такое BISIP? Итак, что же такое BISIP? Это язык для развертывания ресурсов Azure, по сути, являющийся транспейлером. Вы пишете код на BISIP? А он компилируется в JSON для ARM. Тот же движок в основе, но гораздо более чистый способ написания. Кстати, название BISIP — это ARM, прочитанное наоборот BISIP.

ARM — маленькая шутка от Microsoft. Но когда увидишь это в действии, все становится понятно. BISIP работает поверх ARM, а не заменяет его. Вы получаете ту же мощность с более простым синтаксисом. BISIP не заменяет ARM, он его дополняет. Все, что можно сделать в ARM, можно сделать и в BISIP. Любой тип ресурса, любая версия API, любые параметры конфигурации — все доступно. Разница только в том, как вы это пишете. Синтаксис гораздо чище. Никаких кавычек у имен-свойств, запятых между ними и лишних скобок. Просто и удобно. Сравните обе версии бок о бок. Версия JSON для ARM наполнена лишним шумом. Кавычки, запятые, скобки, вложенность. Версия BISIP содержит ту же информацию, но она читабельна. Можно сразу понять, что делает код, не продираясь сквозь дебри синтаксиса JSON. Одно из больших улучшений — автоматическое определение зависимостей. В ARM приходится вручную прописывать Dependison. В BISIP, если ресурс оссылается на ресурс B, система сама понимает зависимость.

Вам не нужно описывать это вручную. Оно просто работает. Одно — это экономит часы отладки. Модули — еще одна важная часть. Вы можете разбивать инфраструктуру на мелкие переиспользуемые части и делиться ими в проектах. Одна команда создает сетевой модуль, а другая использует его. Не нужно каждый раз изобретать велосипед. Параметры и переменные позволяют определить входные данные один раз и использовать везде. Больше не нужно искать и заменять жестко прописанные значения. А интерполяция строк позволяет писать префикс хранилища вместо сложных функций конкатенации. Инструментарий — еще одна причина, по которой с BISIP приятно работать. Расширение VS Code дает интеллисенс — подсветку синтаксиса и проверку ошибок в реальном времени. Честно говоря, это одно из лучших языковых расширений в VS Code. Вы начинаете печатать, и оно подсказывает, что идет дальше. Допустили ошибку — оно сразу сообщит. Не нужно ждать ошибки развертывания, чтобы понять, что пропустили запятую.

Итак, как это выглядит на практике? Давайте посмотрим, чем BISIP отличается от ARM. BISIP против ARM — в чем реальная разница? Давайте обсудим, что на самом деле меняется, когда вы пишете на BISIP вместо ARM JSON. Размер файла — это очевидное отличие. Файлы BISIP примерно в два раза меньше эквивалентных шаблонов ARM. Это вовсе не преувеличение. Вы убираете все кавычки, запятые, скобки и шаблонный код, оставляя только описание инфраструктуры. В два раза меньше кода — тот же результат. Читаемость улучшается сама собой. Меньше строк, более чистая структура и легкость понимания с первого взгляда. Открывая файл BISIP, вы можете быстро просмотреть его и понять, что именно развертывается. В ARM JSON вам приходится пробираться через уровни вложенности, чтобы найти настройки ресурса. Зависимости значительно экономят время. В ARM вы вручную объявляете Dependsum. Пропустите один, и развертывание завершится ошибкой.

В BISIP, если ресурса ссылается на ресурс B, система обрабатывает это автоматически. Она сама добавляет зависимость при компиляции VRM JSON. Вам не нужно об этом думать, все просто работает. И только это экономит часы отладки. Модули — еще одно важное отличие. В ARM были вложенные шаблоны, но работать с ними было мучительно. Отдельные файлы, сложные связи, трудности с версионированием. В BISIP есть модули, которые более чистые, версионируемые и переиспользуемые. Вы создаете модуль один раз, публикуете его в реестр и ссылаетесь на него откуда угодно. Один и тот же модуль, одна и та же конфигурация каждый раз. Сам процесс развертывания остается идентичным. BISIP компилируется в ARM JSON, а затем Azure Resource Manager развертывает его. Тот же движок, тот же конвейер. Вам не нужно менять процесс развертывания, вы просто меняете способ написания шаблонов. VOTIF — это функция, которая технически есть в ARM, но BISIP делает ее намного доступнее.

Вы можете просмотреть изменения перед развертыванием и увидеть, что именно будет создано, изменено или удалено. Никаких сюрпризов, никаких случайных удалений. Вы запускаете VOTIF, проверяете вывод и, если все верно, выполняете развертывание. Кривая обучения — это область, в которой BISIP выделяется особенно сильно. ARM JSON предполагает, что вы точно знаете, что делаете. Он создан для машин, а не для людей. BISIP создан для новичков. Интуитивно понятный синтаксис и инструменты, которые вас направляют. Вы можете освоить его за полдня и стать продуктивными уже к концу недели. Microsoft сделала BISIP рекомендуемым инструментом для написания шаблонов. Все новые функции и улучшения в первую очередь появляются в BISIP. Шаблоны ARM все еще работают и никуда не исчезнут. Но вам, вероятно, уже не стоит писать новые. Если вы начинаете новый проект сегодня, выбирайте BISIP. Три строки на BISIP для развертывания группы ресурсов.

Всего три строки. Эквивалентный код на ARM JSON занял бы около 15 строк. Тот же результат — тоже развертывание. Но одно читабельно, а другое — просто шум. Теперь вы можете задаться вопросом, а как же Terraform? Что мне учить, BISIP или Terraform? BISIP против Terraform. Что стоит использовать? С возвращением на Microsoft Knowledge на Getas. Я Мирко Питерс, и сегодня мы ответим на вопрос, который постоянно возникает. BISIP или Terraform? Давайте разберемся. Terraform работает с несколькими облаками. Вы можете использовать его для Azure, AWS, GCP или даже для всех трех сразу. BISIP, с другой стороны, создан исключительно для Azure. Это ключевое различие влияет на все остальное. Если вы работаете с несколькими облаками, Terraform — ваш выбор. Вы учите один язык, один инструмент, один рабочий процесс, и это работает везде. Но если вы в основном используете Azure, у BISIP есть реальные преимущества.

Вот первое из них. Нет файла состояния, которым нужно управлять. Terraform хранит файл состояния, очлеживающий развертывание, и этот файл критически важен. Если он повреждается или рассинхронизируется, у вас серьезные проблемы. Вам нужно безопасно хранить его, делать резервные копии и управлять доступом. BISIP напрямую общается с Azure Resource Manager, проверяя, что уже есть, и выявляя различия. Нет файла состояния, нет проблем с синхронизацией и риска повреждения. Второе преимущество — поддержка в день выпуска. Когда Microsoft выпускает новую функцию Azure, BISIP поддерживает ее немедленно, в тот же день. Terraform должен ждать обновления провайдера, что бывает быстро, а иногда занимает недели. Если вам нужно использовать новую функцию сразу, BISIP — единственный вариант. Третье — он создан командой Azure. Инструментарий, IntelliSense, сообщение об ошибках — все спроектировано с учетом работы Azure.

Когда вы пишете на BISIP, вы используете язык, который понимает ресурсы Azure нативно. Он знает, какие свойства обязательны, какие значения допустимы и какие есть зависимости. Эту глубокую интеграцию сложно повторить стороннему инструменту. Вы также можете использовать оба. Многие организации используют BISIP для платформы и целевых зон, а Terraform — для мультиоблачных нагрузок. Они не являются взаимоисключающими. Вы можете выбрать подходящий инструмент для каждой задачи. Честный ответ таков. Для изучения именно Azure в BISIP меньше сложностей. Это более простой путь для начинающих. Вам не нужно изучать файлы состояния, провайдеры или конфигурацию бэкенда. Вы устанавливаете Azure CLI, открываете VS Code и начинаете писать. Хватит теории. Давайте обсудим, что вам действительно нужно для начала. Начало работы. Что вам действительно нужно? Для начала вам понадобятся две вещи. Azure CLI и расширение BISIP для VS Code.

Это все. Не нужно устанавливать отдельный BISIP CLI или настраивать дополнительные инструменты. BISIP уже встроен в Azure CLI. Установить Azure CLI довольно просто. Перейдите в Microsoft Docs. Найдите страницу установки для вашей операционной системы. Если у вас Mac, потребуется всего одна команда. Brew Install или Azure CLI. Для Windows есть установщик MSI. Скачайте его, запустите и готово. На Linux это работает через ваш менеджер пакетов. После установки выполните ASVersion, чтобы убедиться, что все работает. Вы должны увидеть версию Azure CLI и версию BISIP в списке. Теперь откройте VS Code, перейдите на панель расширений слева и найдите BISIP. Установите расширение от Microsoft, официальное, а не стороннее. Это расширение вам действительно необходимо. Оно предоставляет интеллисенс, который подсказывает свойства ресурсов, подсвечивает синтаксис для быстрого поиска ошибок и проверяет их в реальном времени.

Вы увидите красные волнистые линии под ошибочным кодом еще до попытки развертывания. Честно говоря, это одно из лучших языковых расширений в VS Code и главная причина, почему с BISIP так приятно работать. Теперь создайте новый файл и назовите его main – BISIP. Расширение BISIP активируется в VS Code автоматически. Без него вы пишете просто обычный текст. С ним вы получаете полноценный набор инструментов. Вот быстрый пример. Развертывание группы ресурсов в три строки кода. Сначала задаете область действия подпиской, затем определяете ресурс, группу ресурсов с именем и расположением. Вот и все. Три строки. Сравните это с аналогом на ARM.js.on, где около 15 строк скобок и кавычек. Для развертывания используйте Azure CLI. Поскольку развертывание идет на уровне подписки, команда будет az-deployment-sub-create. Вы передаете расположение для метадонных развертывания и указываете путь к файлу BISIP.

Это командная строка, но есть и интерактивный способ. В VS-код нажмите правой кнопкой мыши на файл BISIP и выберите DEPLAY BISIP файл. Он проведет вас через весь процесс. Запросит имя развертывания, выбор подписки, создание или выбор группы ресурсов и уточнит наличие файла параметров. Вы отвечаете «нет» и развертывание начинается. Результат появится на портале Azure. Все то же самое, что при работе на портале, но теперь у вас есть файл, который можно повторно использовать. Вы можете закомметить его в репозиторий, поделиться с командой и запустить снова завтра. А вот и волшебная часть. Запустите то же развертывание снова и посмотрите, что произойдет. Сила и демпатентности. Вот что важно при запуске развертываний. Вы хотите иметь возможность запускать их снова и снова, ничего не ломая. Именно это и дает вам и демпатентность. При первом запуске BISIP файла создается группа ресурсов, но при втором запуске ничего не происходит.

Ни ошибок, ни дубликатов, ничего. BISIP проверяет, что уже есть в Azure, сравнивает это с вашим запросом и сообщает, что менять нечего. Он не пытался создать новую группу ресурсов и не выдал ошибку о том, что она уже существует. Он просто подтвердил, что текущее состояние соответствует желаемому. Представьте это как выполнение git-стейтус в чистом репозитории. Делать нечего. Все уже именно так, как должно быть. В этом сила инфраструктуры как кода. Вы можете запускать развертывание снова и снова и каждый раз получать один и тот же результат. Никаких сюрпризов, никакого расхождения конфигураций. Вы точно знаете, что развернуто, потому что это указано в файле. Файл становится вашим единственным источником истины. Вам не нужно гадать, не забыли ли вы настройку, решать проблему, на моей машине работает, или искать в портале Азур, не изменил ли кто-то что-то. Файл говорит вам, что там находится.

Если вы хотите что-то изменить, вы меняете файл и развертываете снова. Если хотите проверить, вы запускаете развертывание еще раз, и оно подтверждает, что все совпадает. Так вы укрепляете уверенность в своей инфраструктуре. Файл – это источник истины. Не ваша память, не документ Word, не видео на YouTube полугодовой давности, а файл. Итак, какое место BSIB занимает в общей картине Азур? Общая картина. Где место BSIB? BSIB живет внутри экосистемы Azure Resource Manager. Это не отдельный инструмент. Многие думают, что это так, но на самом деле это просто лучший способ писать ARM-шаблоны. По сути, это все тот же ARM, тот же движок развертывания, тот же API, все то же самое. Разница лишь в том, как вы это пишете. И поскольку BSIB компилируется в ARM, все, что работает с ARM, работает и с BSIB. Azure Policy обеспечивает соблюдение требований при ваших развертываниях. RBAC контролирует, кто и что может развертывать.

Cost Management очлеживает расходы на ваши ресурсы. Azure Defops и GitHub Actions развертывают ваши BSIB-файлы через конвейеры. Все это работает идеально, потому что BSIB создает стандартный GSUN для ARM. Вы ничего не теряете при переходе. На самом деле, вы приобретаете ясность. Microsoft построила целую экосистему вокруг BSIB. Azure Verified Modules, или EVM, это курируемая библиотека модулей BSIB и Terraform, созданная по лучшим практикам. Вам не нужно писать все с нуля. Можно использовать готовые модули для типовых задач, таких как виртуальные сети, учетные записи хранения и службы приложений. Они протестированы, поддерживаются и соответствуют принципам UL-эл-арчитектед-фрамеворк. Cloud Adoption Framework включает эталонные реализации BSIB для стандартизированных корпоративных архитектур. Если вы создаете целевую зону, для этого уже есть шаблон BSIB. Стеки развертывания обеспечивают управление жизненным циклом групп ресурсов.

Вы можете развернуть стек, и если удалить ресурс из файла BSIB, стек сам его удалит. Или защитит его от случайного удаления. Решать вам. Экосистема продолжает расти благодаря новым модулям, улучшенным инструментам и глубокой интеграции с EEE Git Hub Copilot. Вы можете описать желаемое простыми словами, и Copilot сгенерирует код BSIB за вас. Microsoft продолжает развивать BSIB как основной инструмент для работы с Азур. Поэтому новые функции в первую очередь появляются в BSIB. Шаблоны ARM все еще работают, но все инновации происходят в BSIB. Итак, подведем итог. Если вы работаете в Азур, BSIB — это естественный шаг после работы через портал. Вам не нужно изучать Terraform или осваивать JSON в ARM. Вы устанавливаете две вещи, пишете несколько строк кода и развертываете инфраструктуру, которую можно повторять, версионировать и на которую можно положиться. Позвольте оставить вам практический совет, который можно применить сегодня.

Теперь вы знаете, что такое инфраструктура как код, зачем нужен BSIB и как он упрощает развертывание в Азур. Вот основная мысль. BSIB — это не новая система развертывания. Это лучший способ написания тех же шаблонов ARM, использующий тот же движок Azure Resource Manager, но на языке, который легко читать и писать человеку. Вот вам небольшое задание. Создайте файл Main, BSIB, разверните группу ресурсов и запустите развертывание дважды. Посмотрите, как это работает оба раза. В первый раз он создает ресурс, а во второй — подтверждает, что изменений нет. Это тот самый момент озарения, когда понимаешь, что больше никогда не захочешь просто кликать по кнопкам в портале. Это фундамент. Отсюда можно добавлять учетные записи хранения, виртуальные сети и службы приложений, используя тот же подход. Напишите файл, разверните его, запустите снова. Этот файл становится вашим единственным источником истины, из которого следует все остальное.

Если это видео было полезным, поделитесь им с тем, кто все еще кликает мышкой по порталу. Они скажут вам спасибо. Подписывайтесь на любимой платформе для подкастов. А в следующем эпизоде мы углубимся в работу с BSIB и начнем развертывать реальные ресурсы с реальными свойствами.