WEBVTT 00:00:00.000 --> 00:00:03.900 Добро пожаловать в очередной выпуск Microsoft Knowledge на Getas на M365FM. 00:00:04.060 --> 00:00:05.520 Я ваш ведущий, Мирку Питерс. 00:00:05.640 --> 00:00:08.320 Вы развертывали ресурсы Azure, просто нажимая на кнопки в портале. 00:00:08.460 --> 00:00:10.260 Все идет хорошо, пока не перестает работать. 00:00:10.480 --> 00:00:13.300 Затем нужно повторить процесс, но вы не можете вспомнить, что именно выбирали. 00:00:13.480 --> 00:00:16.220 Нужно передать задачу коллеге, а он не может повторить ваши действия. 00:00:16.360 --> 00:00:18.300 Контроль версий. Тут нечего комметить. 00:00:18.480 --> 00:00:20.340 Именно эту проблему мы сегодня и решим. 00:00:20.480 --> 00:00:23.640 К концу этого выпуска вы поймете, что такое инфраструктура, как код. 00:00:23.840 --> 00:00:27.320 Зачем нужен BISIP и как он делает развертывание в Azure проще и надежнее. 00:00:27.320 --> 00:00:32.000 Мы начнем с проблемы, затем перейдем к решению, а после – к практическому примеру, который вы сможете повторить. 00:00:32.100 --> 00:00:33.840 Берите кофе и давайте начнем. 00:00:33.980 --> 00:00:34.880 Проблема портала. 00:00:35.060 --> 00:00:37.320 Ловушка развертывания через клики кажется быстрой. 00:00:37.480 --> 00:00:40.240 Вы вошли, заполнили форму, нажали «Создать» и готово. 00:00:40.340 --> 00:00:44.120 Но что делать, когда нужно повторить это с теми же настройками, регионом и соглашением об именовании? 00:00:44.260 --> 00:00:48.020 Вы должны помнить каждую деталь, которую выбрали, и именно здесь все начинает рушиться. 00:00:48.200 --> 00:00:52.780 Ручное развертывание ведет к несоответствиям, человеческим ошибкам и отсутствию аудита. 00:00:52.960 --> 00:00:53.920 Вот пример из жизни. 00:00:53.920 --> 00:00:57.220 Кто-то из вашей команды создает ресурс с немного другими настройками. 00:00:57.320 --> 00:00:59.760 Теперь у вас две среды, которые не совпадают друг с другом. 00:00:59.900 --> 00:01:02.700 Одна работает, другая нет – удача в выяснении причин. 00:01:02.820 --> 00:01:04.520 А еще есть проблема с документацией. 00:01:04.800 --> 00:01:10.620 Инфраструктура в виде документа Word или, что еще хуже, видео на YouTube, записанного полгода назад, когда портал выглядел совсем иначе. 00:01:10.740 --> 00:01:13.540 Функции перемещаются, меню меняются, появляются новые опции. 00:01:13.720 --> 00:01:18.020 Я общался с менеджером по продукту из команды Azure, и он сказал, что они выпускают новые функции дважды в день. 00:01:18.200 --> 00:01:18.800 Дважды в день. 00:01:18.980 --> 00:01:21.580 Ваш документ Word устаревает еще до того, как вы закончите его писать. 00:01:21.580 --> 00:01:22.500 Суть в следующем. 00:01:22.640 --> 00:01:24.220 Нажимать на кнопки удобно для обучения. 00:01:24.380 --> 00:01:25.600 Это не подходит для продакшена. 00:01:27.320 --> 00:01:30.420 Пишите файл с описанием того, что хотите, а затем говорите Azure это создать. 00:01:30.600 --> 00:01:32.160 Что такое инфраструктура как код? 00:01:32.420 --> 00:01:37.120 Инфраструктура как код – это управление облачными настройками с помощью кода вместо кликов по веб-порталу. 00:01:37.260 --> 00:01:38.300 Вот основная идея. 00:01:38.440 --> 00:01:47.580 Вы пишете файл, описывающий инфраструктуру, храните его в репозитории, используете контроль версий, проверяете в пул рекист и запускаете снова завтра, чтобы получить тот же результат. 00:01:47.820 --> 00:01:49.940 Здесь есть ключевой термин – декларативность. 00:01:49.940 --> 00:01:53.400 Это значит, что вы описываете, что хотите получить, а не то, как это построить. 00:01:53.520 --> 00:01:57.300 Вы не говорите Azure, сначала создай группу ресурсов, затем добавь учетную запись хранения. 00:01:57.440 --> 00:01:58.280 А потом настрой сеть. 00:01:58.460 --> 00:02:02.660 Вместо этого вы говорите «Я хочу группу ресурсов с учетной записью хранения и сетью, настроенными вот так». 00:02:02.660 --> 00:02:04.420 А Azure сама определяет порядок действий. 00:02:04.580 --> 00:02:06.140 Результат называется и демпатентностью. 00:02:06.340 --> 00:02:08.940 Запустите код один раз или сто раз, вы получите один и тот же результат. 00:02:09.080 --> 00:02:09.840 В этом вся сила. 00:02:10.000 --> 00:02:12.260 Представьте это как чертеж в противовес строительству вручную. 00:02:12.440 --> 00:02:14.960 Чертеж можно повторно использовать, передавать другим и проверять. 00:02:15.100 --> 00:02:17.680 Передайте его другому человеку, и он построит в точности то же самое. 00:02:17.680 --> 00:02:19.580 Сейчас для этого есть несколько инструментов. 00:02:19.660 --> 00:02:22.020 ARM-шаблоны, BISIP, Terraform, Pulumi. 00:02:22.120 --> 00:02:24.320 Все они реализуют одну и ту же концепцию по-разному. 00:02:24.460 --> 00:02:25.500 Это важное различие. 00:02:25.820 --> 00:02:27.540 Инфраструктура как код – это сама концепция. 00:02:27.720 --> 00:02:29.800 BISIP – лишь один из инструментов ее реализации. 00:02:29.940 --> 00:02:30.700 Но вот в чем дело. 00:02:30.840 --> 00:02:33.840 У Azure уже много лет есть язык для ИК, который называется ARM-шаблоны. 00:02:33.920 --> 00:02:36.140 И есть причина, по которой Microsoft создала новый. 00:02:36.300 --> 00:02:37.580 Проблема ARM-шаблонов. 00:02:37.720 --> 00:02:40.180 ARM-шаблоны – это оригинальный формат ИК для Azure. 00:02:40.360 --> 00:02:42.860 Это JSON-файлы, и у них много преимуществ. 00:02:42.860 --> 00:02:47.700 Полный охват всех ресурсов Azure и тот же движок развертывания, что используется внутри системы. 00:02:47.780 --> 00:02:51.300 Если вы можете создать что-то на портале, вы можете описать это в ARM-шаблоне. 00:02:51.300 --> 00:02:54.940 Так в чем же проблема? JSON-файл хорош для машин, но ужасен для людей. 00:02:55.060 --> 00:02:56.700 Позвольте показать, что я имею в виду. 00:02:56.840 --> 00:02:59.700 Учетная запись хранения в ARM-шаблоне занимает около 20 строк кода. 00:02:59.820 --> 00:03:02.060 Та же учетная запись в BISIP – около 10 строк. 00:03:02.360 --> 00:03:04.300 JSON-версия примерно в два раза больше. 00:03:04.480 --> 00:03:05.700 И это лишь простой ресурс. 00:03:05.800 --> 00:03:10.100 Представьте полноценное развертывание с сетью, вычислениями, базами данных и правилами безопасности. 00:03:10.240 --> 00:03:12.740 ARM-шаблон превращается в сплошную стену текста. 00:03:12.880 --> 00:03:14.780 Типичные проблемы вполне предсказуемы. 00:03:14.780 --> 00:03:20.520 Пропущенные запятые, непарные скобки, громоздкая вложенность, из-за которой трудно понять, где заканчивается один ресурс и начинается другой. 00:03:20.680 --> 00:03:24.760 Вы тратите больше времени на борьбу с синтаксисом JSON, чем на описание инфраструктуры. 00:03:24.880 --> 00:03:26.060 А еще есть зависимости. 00:03:26.280 --> 00:03:28.800 В ARM вы должны вручную объявлять Dependison. 00:03:29.040 --> 00:03:33.280 Если ресурсу а нужно, чтобы сначала существовал ресурс, вы должны прописать это явно. 00:03:33.400 --> 00:03:35.520 Пропустите один, и развертывание не удастся. 00:03:35.680 --> 00:03:37.720 Удачи в попытках понять, какой именно вы пропустили. 00:03:37.840 --> 00:03:41.320 Если вы хоть раз пытались написать 200-строчный JSON-файл вручную, вы знаете, это не весело. 00:03:41.480 --> 00:03:42.240 Совсем не весело. 00:03:42.240 --> 00:03:43.920 Кривая обучения довольно крутая. 00:03:44.080 --> 00:03:46.500 Новым членам команды трудно разобраться в ARM-шаблонах. 00:03:46.600 --> 00:03:47.940 Порог вхождения очень высок. 00:03:48.080 --> 00:03:49.380 И что происходит на практике? 00:03:49.540 --> 00:03:52.520 Во многих командах остается только один человек, знающий ARM-шаблоны. 00:03:52.620 --> 00:03:54.660 Этот человек становится единой точкой отказа. 00:03:54.740 --> 00:03:58.740 Только он может изменять развертывание, и только он может отлаживать его, если что-то сломается. 00:03:58.920 --> 00:03:59.800 Это нерационально. 00:03:59.980 --> 00:04:04.040 Microsoft услышала отзывы и создала BISIP, чтобы решить именно эти проблемы. 00:04:04.240 --> 00:04:05.200 Что такое BISIP? 00:04:05.360 --> 00:04:06.920 Итак, что же такое BISIP? 00:04:07.020 --> 00:04:10.900 Это язык для развертывания ресурсов Azure, по сути, являющийся транспейлером. 00:04:10.900 --> 00:04:12.100 Вы пишете код на BISIP? 00:04:12.240 --> 00:04:14.100 А он компилируется в JSON для ARM. 00:04:14.280 --> 00:04:16.920 Тот же движок в основе, но гораздо более чистый способ написания. 00:04:17.060 --> 00:04:20.200 Кстати, название BISIP — это ARM, прочитанное наоборот BISIP. 00:04:20.300 --> 00:04:22.180 ARM — маленькая шутка от Microsoft. 00:04:22.440 --> 00:04:24.520 Но когда увидишь это в действии, все становится понятно. 00:04:24.740 --> 00:04:26.700 BISIP работает поверх ARM, а не заменяет его. 00:04:26.860 --> 00:04:29.040 Вы получаете ту же мощность с более простым синтаксисом. 00:04:29.200 --> 00:04:31.260 BISIP не заменяет ARM, он его дополняет. 00:04:31.380 --> 00:04:33.760 Все, что можно сделать в ARM, можно сделать и в BISIP. 00:04:33.900 --> 00:04:37.260 Любой тип ресурса, любая версия API, любые параметры конфигурации — все доступно. 00:04:37.420 --> 00:04:39.160 Разница только в том, как вы это пишете. 00:04:39.160 --> 00:04:40.600 Синтаксис гораздо чище. 00:04:40.740 --> 00:04:44.160 Никаких кавычек у имен-свойств, запятых между ними и лишних скобок. 00:04:44.280 --> 00:04:45.120 Просто и удобно. 00:04:45.280 --> 00:04:46.900 Сравните обе версии бок о бок. 00:04:47.120 --> 00:04:49.920 Версия JSON для ARM наполнена лишним шумом. 00:04:50.020 --> 00:04:52.600 Кавычки, запятые, скобки, вложенность. 00:04:52.780 --> 00:04:55.900 Версия BISIP содержит ту же информацию, но она читабельна. 00:04:56.100 --> 00:05:00.160 Можно сразу понять, что делает код, не продираясь сквозь дебри синтаксиса JSON. 00:05:00.980 --> 00:05:04.220 Одно из больших улучшений — автоматическое определение зависимостей. 00:05:04.220 --> 00:05:06.960 В ARM приходится вручную прописывать Dependison. 00:05:07.140 --> 00:05:11.940 В BISIP, если ресурс оссылается на ресурс B, система сама понимает зависимость. 00:05:12.160 --> 00:05:13.740 Вам не нужно описывать это вручную. 00:05:13.940 --> 00:05:14.800 Оно просто работает. 00:05:15.040 --> 00:05:16.640 Одно — это экономит часы отладки. 00:05:16.820 --> 00:05:18.460 Модули — еще одна важная часть. 00:05:18.680 --> 00:05:23.060 Вы можете разбивать инфраструктуру на мелкие переиспользуемые части и делиться ими в проектах. 00:05:23.200 --> 00:05:26.200 Одна команда создает сетевой модуль, а другая использует его. 00:05:26.420 --> 00:05:28.320 Не нужно каждый раз изобретать велосипед. 00:05:28.480 --> 00:05:32.400 Параметры и переменные позволяют определить входные данные один раз и использовать везде. 00:05:32.400 --> 00:05:35.420 Больше не нужно искать и заменять жестко прописанные значения. 00:05:35.560 --> 00:05:40.140 А интерполяция строк позволяет писать префикс хранилища вместо сложных функций конкатенации. 00:05:40.440 --> 00:05:43.420 Инструментарий — еще одна причина, по которой с BISIP приятно работать. 00:05:43.620 --> 00:05:47.900 Расширение VS Code дает интеллисенс — подсветку синтаксиса и проверку ошибок в реальном времени. 00:05:48.080 --> 00:05:50.960 Честно говоря, это одно из лучших языковых расширений в VS Code. 00:05:51.120 --> 00:05:53.680 Вы начинаете печатать, и оно подсказывает, что идет дальше. 00:05:53.920 --> 00:05:55.800 Допустили ошибку — оно сразу сообщит. 00:05:55.920 --> 00:05:59.200 Не нужно ждать ошибки развертывания, чтобы понять, что пропустили запятую. 00:05:59.200 --> 00:06:01.080 Итак, как это выглядит на практике? 00:06:01.240 --> 00:06:03.560 Давайте посмотрим, чем BISIP отличается от ARM. 00:06:03.700 --> 00:06:05.820 BISIP против ARM — в чем реальная разница? 00:06:06.020 --> 00:06:09.600 Давайте обсудим, что на самом деле меняется, когда вы пишете на BISIP вместо ARM JSON. 00:06:09.900 --> 00:06:11.740 Размер файла — это очевидное отличие. 00:06:11.920 --> 00:06:15.280 Файлы BISIP примерно в два раза меньше эквивалентных шаблонов ARM. 00:06:15.420 --> 00:06:16.680 Это вовсе не преувеличение. 00:06:16.880 --> 00:06:21.220 Вы убираете все кавычки, запятые, скобки и шаблонный код, оставляя только описание инфраструктуры. 00:06:21.360 --> 00:06:23.140 В два раза меньше кода — тот же результат. 00:06:23.340 --> 00:06:24.820 Читаемость улучшается сама собой. 00:06:25.020 --> 00:06:28.020 Меньше строк, более чистая структура и легкость понимания с первого взгляда. 00:06:28.020 --> 00:06:31.640 Открывая файл BISIP, вы можете быстро просмотреть его и понять, что именно развертывается. 00:06:31.840 --> 00:06:36.120 В ARM JSON вам приходится пробираться через уровни вложенности, чтобы найти настройки ресурса. 00:06:36.360 --> 00:06:38.120 Зависимости значительно экономят время. 00:06:38.340 --> 00:06:40.300 В ARM вы вручную объявляете Dependsum. 00:06:40.440 --> 00:06:42.760 Пропустите один, и развертывание завершится ошибкой. 00:06:42.880 --> 00:06:46.820 В BISIP, если ресурса ссылается на ресурс B, система обрабатывает это автоматически. 00:06:47.000 --> 00:06:49.560 Она сама добавляет зависимость при компиляции VRM JSON. 00:06:49.880 --> 00:06:51.860 Вам не нужно об этом думать, все просто работает. 00:06:52.020 --> 00:06:53.740 И только это экономит часы отладки. 00:06:53.900 --> 00:06:55.560 Модули — еще одно важное отличие. 00:06:55.560 --> 00:06:58.360 В ARM были вложенные шаблоны, но работать с ними было мучительно. 00:06:58.540 --> 00:07:01.160 Отдельные файлы, сложные связи, трудности с версионированием. 00:07:01.320 --> 00:07:04.860 В BISIP есть модули, которые более чистые, версионируемые и переиспользуемые. 00:07:05.020 --> 00:07:08.820 Вы создаете модуль один раз, публикуете его в реестр и ссылаетесь на него откуда угодно. 00:07:08.980 --> 00:07:11.500 Один и тот же модуль, одна и та же конфигурация каждый раз. 00:07:11.680 --> 00:07:13.700 Сам процесс развертывания остается идентичным. 00:07:13.860 --> 00:07:17.180 BISIP компилируется в ARM JSON, а затем Azure Resource Manager развертывает его. 00:07:17.320 --> 00:07:18.740 Тот же движок, тот же конвейер. 00:07:18.880 --> 00:07:22.500 Вам не нужно менять процесс развертывания, вы просто меняете способ написания шаблонов. 00:07:22.500 --> 00:07:26.860 VOTIF — это функция, которая технически есть в ARM, но BISIP делает ее намного доступнее. 00:07:27.000 --> 00:07:31.480 Вы можете просмотреть изменения перед развертыванием и увидеть, что именно будет создано, изменено или удалено. 00:07:31.660 --> 00:07:33.720 Никаких сюрпризов, никаких случайных удалений. 00:07:33.860 --> 00:07:36.800 Вы запускаете VOTIF, проверяете вывод и, если все верно, выполняете развертывание. 00:07:36.940 --> 00:07:39.300 Кривая обучения — это область, в которой BISIP выделяется особенно сильно. 00:07:39.460 --> 00:07:41.660 ARM JSON предполагает, что вы точно знаете, что делаете. 00:07:41.820 --> 00:07:43.320 Он создан для машин, а не для людей. 00:07:43.520 --> 00:07:44.660 BISIP создан для новичков. 00:07:44.840 --> 00:07:47.160 Интуитивно понятный синтаксис и инструменты, которые вас направляют. 00:07:47.160 --> 00:07:49.780 Вы можете освоить его за полдня и стать продуктивными уже к концу недели. 00:07:49.880 --> 00:07:52.680 Microsoft сделала BISIP рекомендуемым инструментом для написания шаблонов. 00:07:52.820 --> 00:07:55.440 Все новые функции и улучшения в первую очередь появляются в BISIP. 00:07:55.560 --> 00:07:57.760 Шаблоны ARM все еще работают и никуда не исчезнут. 00:07:57.940 --> 00:07:59.680 Но вам, вероятно, уже не стоит писать новые. 00:07:59.840 --> 00:08:02.520 Если вы начинаете новый проект сегодня, выбирайте BISIP. 00:08:02.620 --> 00:08:05.120 Три строки на BISIP для развертывания группы ресурсов. 00:08:05.240 --> 00:08:05.980 Всего три строки. 00:08:06.260 --> 00:08:08.840 Эквивалентный код на ARM JSON занял бы около 15 строк. 00:08:08.920 --> 00:08:10.340 Тот же результат — тоже развертывание. 00:08:10.480 --> 00:08:12.300 Но одно читабельно, а другое — просто шум. 00:08:12.300 --> 00:08:14.740 Теперь вы можете задаться вопросом, а как же Terraform? 00:08:14.940 --> 00:08:16.700 Что мне учить, BISIP или Terraform? 00:08:16.900 --> 00:08:18.060 BISIP против Terraform. 00:08:18.300 --> 00:08:19.220 Что стоит использовать? 00:08:19.400 --> 00:08:21.560 С возвращением на Microsoft Knowledge на Getas. 00:08:21.760 --> 00:08:24.780 Я Мирко Питерс, и сегодня мы ответим на вопрос, который постоянно возникает. 00:08:24.900 --> 00:08:25.900 BISIP или Terraform? 00:08:26.100 --> 00:08:26.880 Давайте разберемся. 00:08:27.080 --> 00:08:28.800 Terraform работает с несколькими облаками. 00:08:28.940 --> 00:08:32.240 Вы можете использовать его для Azure, AWS, GCP или даже для всех трех сразу. 00:08:32.440 --> 00:08:34.820 BISIP, с другой стороны, создан исключительно для Azure. 00:08:34.960 --> 00:08:37.040 Это ключевое различие влияет на все остальное. 00:08:37.240 --> 00:08:40.620 Если вы работаете с несколькими облаками, Terraform — ваш выбор. 00:08:40.620 --> 00:08:45.040 Вы учите один язык, один инструмент, один рабочий процесс, и это работает везде. 00:08:45.220 --> 00:08:48.740 Но если вы в основном используете Azure, у BISIP есть реальные преимущества. 00:08:48.920 --> 00:08:49.820 Вот первое из них. 00:08:50.000 --> 00:08:52.060 Нет файла состояния, которым нужно управлять. 00:08:52.140 --> 00:08:56.040 Terraform хранит файл состояния, очлеживающий развертывание, и этот файл критически важен. 00:08:56.160 --> 00:08:59.080 Если он повреждается или рассинхронизируется, у вас серьезные проблемы. 00:08:59.300 --> 00:09:02.660 Вам нужно безопасно хранить его, делать резервные копии и управлять доступом. 00:09:02.820 --> 00:09:07.440 BISIP напрямую общается с Azure Resource Manager, проверяя, что уже есть, и выявляя различия. 00:09:07.440 --> 00:09:11.040 Нет файла состояния, нет проблем с синхронизацией и риска повреждения. 00:09:11.180 --> 00:09:13.480 Второе преимущество — поддержка в день выпуска. 00:09:13.600 --> 00:09:18.060 Когда Microsoft выпускает новую функцию Azure, BISIP поддерживает ее немедленно, в тот же день. 00:09:18.220 --> 00:09:22.660 Terraform должен ждать обновления провайдера, что бывает быстро, а иногда занимает недели. 00:09:22.840 --> 00:09:26.440 Если вам нужно использовать новую функцию сразу, BISIP — единственный вариант. 00:09:26.620 --> 00:09:28.380 Третье — он создан командой Azure. 00:09:28.720 --> 00:09:33.380 Инструментарий, IntelliSense, сообщение об ошибках — все спроектировано с учетом работы Azure. 00:09:33.380 --> 00:09:37.880 Когда вы пишете на BISIP, вы используете язык, который понимает ресурсы Azure нативно. 00:09:37.980 --> 00:09:42.060 Он знает, какие свойства обязательны, какие значения допустимы и какие есть зависимости. 00:09:42.220 --> 00:09:45.060 Эту глубокую интеграцию сложно повторить стороннему инструменту. 00:09:45.160 --> 00:09:46.600 Вы также можете использовать оба. 00:09:46.720 --> 00:09:51.140 Многие организации используют BISIP для платформы и целевых зон, а Terraform — для мультиоблачных нагрузок. 00:09:51.240 --> 00:09:52.960 Они не являются взаимоисключающими. 00:09:53.100 --> 00:09:55.520 Вы можете выбрать подходящий инструмент для каждой задачи. 00:09:55.620 --> 00:09:56.660 Честный ответ таков. 00:09:56.780 --> 00:09:59.440 Для изучения именно Azure в BISIP меньше сложностей. 00:09:59.560 --> 00:10:01.380 Это более простой путь для начинающих. 00:10:01.380 --> 00:10:04.720 Вам не нужно изучать файлы состояния, провайдеры или конфигурацию бэкенда. 00:10:04.820 --> 00:10:08.160 Вы устанавливаете Azure CLI, открываете VS Code и начинаете писать. 00:10:08.280 --> 00:10:09.080 Хватит теории. 00:10:09.260 --> 00:10:11.680 Давайте обсудим, что вам действительно нужно для начала. 00:10:11.900 --> 00:10:12.660 Начало работы. 00:10:12.860 --> 00:10:14.000 Что вам действительно нужно? 00:10:14.220 --> 00:10:15.920 Для начала вам понадобятся две вещи. 00:10:16.120 --> 00:10:18.720 Azure CLI и расширение BISIP для VS Code. 00:10:18.840 --> 00:10:19.240 Это все. 00:10:19.440 --> 00:10:22.720 Не нужно устанавливать отдельный BISIP CLI или настраивать дополнительные инструменты. 00:10:22.880 --> 00:10:24.460 BISIP уже встроен в Azure CLI. 00:10:24.620 --> 00:10:26.400 Установить Azure CLI довольно просто. 00:10:26.560 --> 00:10:27.860 Перейдите в Microsoft Docs. 00:10:28.000 --> 00:10:30.280 Найдите страницу установки для вашей операционной системы. 00:10:30.280 --> 00:10:32.440 Если у вас Mac, потребуется всего одна команда. 00:10:32.600 --> 00:10:34.020 Brew Install или Azure CLI. 00:10:34.160 --> 00:10:35.860 Для Windows есть установщик MSI. 00:10:36.000 --> 00:10:37.780 Скачайте его, запустите и готово. 00:10:37.880 --> 00:10:40.000 На Linux это работает через ваш менеджер пакетов. 00:10:40.120 --> 00:10:43.460 После установки выполните ASVersion, чтобы убедиться, что все работает. 00:10:43.660 --> 00:10:47.000 Вы должны увидеть версию Azure CLI и версию BISIP в списке. 00:10:47.140 --> 00:10:51.300 Теперь откройте VS Code, перейдите на панель расширений слева и найдите BISIP. 00:10:51.440 --> 00:10:54.780 Установите расширение от Microsoft, официальное, а не стороннее. 00:10:54.920 --> 00:10:56.740 Это расширение вам действительно необходимо. 00:10:56.740 --> 00:11:00.000 Оно предоставляет интеллисенс, который подсказывает свойства ресурсов, 00:11:00.140 --> 00:11:03.620 подсвечивает синтаксис для быстрого поиска ошибок и проверяет их в реальном времени. 00:11:03.820 --> 00:11:07.660 Вы увидите красные волнистые линии под ошибочным кодом еще до попытки развертывания. 00:11:07.820 --> 00:11:11.300 Честно говоря, это одно из лучших языковых расширений в VS Code и главная причина, 00:11:11.440 --> 00:11:12.800 почему с BISIP так приятно работать. 00:11:12.940 --> 00:11:15.680 Теперь создайте новый файл и назовите его main – BISIP. 00:11:15.820 --> 00:11:18.460 Расширение BISIP активируется в VS Code автоматически. 00:11:18.660 --> 00:11:20.440 Без него вы пишете просто обычный текст. 00:11:20.640 --> 00:11:22.960 С ним вы получаете полноценный набор инструментов. 00:11:22.960 --> 00:11:26.460 Вот быстрый пример. Развертывание группы ресурсов в три строки кода. 00:11:26.660 --> 00:11:30.180 Сначала задаете область действия подпиской, затем определяете ресурс, 00:11:30.300 --> 00:11:32.180 группу ресурсов с именем и расположением. 00:11:32.380 --> 00:11:33.540 Вот и все. Три строки. 00:11:33.760 --> 00:11:38.180 Сравните это с аналогом на ARM.js.on, где около 15 строк скобок и кавычек. 00:11:38.300 --> 00:11:40.480 Для развертывания используйте Azure CLI. 00:11:40.600 --> 00:11:44.860 Поскольку развертывание идет на уровне подписки, команда будет az-deployment-sub-create. 00:11:45.040 --> 00:11:48.820 Вы передаете расположение для метадонных развертывания и указываете путь к файлу BISIP. 00:11:48.900 --> 00:11:51.500 Это командная строка, но есть и интерактивный способ. 00:11:51.500 --> 00:11:55.580 В VS-код нажмите правой кнопкой мыши на файл BISIP и выберите DEPLAY BISIP файл. 00:11:55.680 --> 00:11:57.220 Он проведет вас через весь процесс. 00:11:57.460 --> 00:12:02.020 Запросит имя развертывания, выбор подписки, создание или выбор группы ресурсов 00:12:02.020 --> 00:12:03.860 и уточнит наличие файла параметров. 00:12:04.040 --> 00:12:06.300 Вы отвечаете «нет» и развертывание начинается. 00:12:06.480 --> 00:12:07.940 Результат появится на портале Azure. 00:12:08.100 --> 00:12:11.300 Все то же самое, что при работе на портале, но теперь у вас есть файл, который можно повторно использовать. 00:12:11.480 --> 00:12:14.800 Вы можете закомметить его в репозиторий, поделиться с командой и запустить снова завтра. 00:12:14.940 --> 00:12:16.080 А вот и волшебная часть. 00:12:16.320 --> 00:12:19.540 Запустите то же развертывание снова и посмотрите, что произойдет. 00:12:19.540 --> 00:12:20.840 Сила и демпатентности. 00:12:21.040 --> 00:12:22.760 Вот что важно при запуске развертываний. 00:12:22.920 --> 00:12:25.800 Вы хотите иметь возможность запускать их снова и снова, ничего не ломая. 00:12:25.960 --> 00:12:27.740 Именно это и дает вам и демпатентность. 00:12:27.880 --> 00:12:30.660 При первом запуске BISIP файла создается группа ресурсов, 00:12:30.840 --> 00:12:32.620 но при втором запуске ничего не происходит. 00:12:32.820 --> 00:12:34.760 Ни ошибок, ни дубликатов, ничего. 00:12:35.000 --> 00:12:39.620 BISIP проверяет, что уже есть в Azure, сравнивает это с вашим запросом и сообщает, что менять нечего. 00:12:39.780 --> 00:12:43.940 Он не пытался создать новую группу ресурсов и не выдал ошибку о том, что она уже существует. 00:12:43.940 --> 00:12:47.140 Он просто подтвердил, что текущее состояние соответствует желаемому. 00:12:47.280 --> 00:12:50.060 Представьте это как выполнение git-стейтус в чистом репозитории. 00:12:50.260 --> 00:12:50.940 Делать нечего. 00:12:51.140 --> 00:12:52.900 Все уже именно так, как должно быть. 00:12:53.080 --> 00:12:54.840 В этом сила инфраструктуры как кода. 00:12:55.020 --> 00:12:58.540 Вы можете запускать развертывание снова и снова и каждый раз получать один и тот же результат. 00:12:58.760 --> 00:13:00.860 Никаких сюрпризов, никакого расхождения конфигураций. 00:13:01.000 --> 00:13:03.460 Вы точно знаете, что развернуто, потому что это указано в файле. 00:13:03.600 --> 00:13:05.900 Файл становится вашим единственным источником истины. 00:13:06.060 --> 00:13:10.260 Вам не нужно гадать, не забыли ли вы настройку, решать проблему, на моей машине работает, 00:13:10.260 --> 00:13:13.000 или искать в портале Азур, не изменил ли кто-то что-то. 00:13:13.160 --> 00:13:14.800 Файл говорит вам, что там находится. 00:13:15.040 --> 00:13:17.860 Если вы хотите что-то изменить, вы меняете файл и развертываете снова. 00:13:18.060 --> 00:13:22.200 Если хотите проверить, вы запускаете развертывание еще раз, и оно подтверждает, что все совпадает. 00:13:22.280 --> 00:13:24.580 Так вы укрепляете уверенность в своей инфраструктуре. 00:13:24.720 --> 00:13:26.340 Файл – это источник истины. 00:13:26.520 --> 00:13:31.120 Не ваша память, не документ Word, не видео на YouTube полугодовой давности, а файл. 00:13:31.260 --> 00:13:34.280 Итак, какое место BSIB занимает в общей картине Азур? 00:13:34.400 --> 00:13:35.300 Общая картина. 00:13:35.560 --> 00:13:36.480 Где место BSIB? 00:13:36.480 --> 00:13:39.380 BSIB живет внутри экосистемы Azure Resource Manager. 00:13:39.540 --> 00:13:40.680 Это не отдельный инструмент. 00:13:40.960 --> 00:13:44.920 Многие думают, что это так, но на самом деле это просто лучший способ писать ARM-шаблоны. 00:13:45.000 --> 00:13:48.820 По сути, это все тот же ARM, тот же движок развертывания, тот же API, все то же самое. 00:13:49.020 --> 00:13:50.660 Разница лишь в том, как вы это пишете. 00:13:50.800 --> 00:13:54.780 И поскольку BSIB компилируется в ARM, все, что работает с ARM, работает и с BSIB. 00:13:54.860 --> 00:13:57.740 Azure Policy обеспечивает соблюдение требований при ваших развертываниях. 00:13:57.860 --> 00:14:00.020 RBAC контролирует, кто и что может развертывать. 00:14:00.160 --> 00:14:02.400 Cost Management очлеживает расходы на ваши ресурсы. 00:14:02.400 --> 00:14:05.940 Azure Defops и GitHub Actions развертывают ваши BSIB-файлы через конвейеры. 00:14:05.940 --> 00:14:09.280 Все это работает идеально, потому что BSIB создает стандартный GSUN для ARM. 00:14:09.460 --> 00:14:10.940 Вы ничего не теряете при переходе. 00:14:11.060 --> 00:14:12.980 На самом деле, вы приобретаете ясность. 00:14:13.120 --> 00:14:15.760 Microsoft построила целую экосистему вокруг BSIB. 00:14:15.860 --> 00:14:21.320 Azure Verified Modules, или EVM, это курируемая библиотека модулей BSIB и Terraform, созданная по лучшим практикам. 00:14:21.500 --> 00:14:22.820 Вам не нужно писать все с нуля. 00:14:23.020 --> 00:14:28.360 Можно использовать готовые модули для типовых задач, таких как виртуальные сети, учетные записи хранения и службы приложений. 00:14:28.480 --> 00:14:32.240 Они протестированы, поддерживаются и соответствуют принципам UL-эл-арчитектед-фрамеворк. 00:14:32.240 --> 00:14:37.100 Cloud Adoption Framework включает эталонные реализации BSIB для стандартизированных корпоративных архитектур. 00:14:37.200 --> 00:14:40.360 Если вы создаете целевую зону, для этого уже есть шаблон BSIB. 00:14:40.520 --> 00:14:44.120 Стеки развертывания обеспечивают управление жизненным циклом групп ресурсов. 00:14:44.240 --> 00:14:48.900 Вы можете развернуть стек, и если удалить ресурс из файла BSIB, стек сам его удалит. 00:14:49.040 --> 00:14:51.140 Или защитит его от случайного удаления. 00:14:51.360 --> 00:14:51.920 Решать вам. 00:14:51.920 --> 00:14:57.780 Экосистема продолжает расти благодаря новым модулям, улучшенным инструментам и глубокой интеграции с EEE Git Hub Copilot. 00:14:57.920 --> 00:15:02.340 Вы можете описать желаемое простыми словами, и Copilot сгенерирует код BSIB за вас. 00:15:02.480 --> 00:15:06.300 Microsoft продолжает развивать BSIB как основной инструмент для работы с Азур. 00:15:06.400 --> 00:15:09.080 Поэтому новые функции в первую очередь появляются в BSIB. 00:15:09.180 --> 00:15:12.260 Шаблоны ARM все еще работают, но все инновации происходят в BSIB. 00:15:12.360 --> 00:15:13.480 Итак, подведем итог. 00:15:13.480 --> 00:15:17.400 Если вы работаете в Азур, BSIB — это естественный шаг после работы через портал. 00:15:17.400 --> 00:15:20.200 Вам не нужно изучать Terraform или осваивать JSON в ARM. 00:15:20.440 --> 00:15:23.840 Вы устанавливаете две вещи, пишете несколько строк кода и развертываете инфраструктуру, 00:15:23.920 --> 00:15:26.340 которую можно повторять, версионировать и на которую можно положиться. 00:15:26.480 --> 00:15:29.360 Позвольте оставить вам практический совет, который можно применить сегодня. 00:15:29.520 --> 00:15:34.400 Теперь вы знаете, что такое инфраструктура как код, зачем нужен BSIB и как он упрощает развертывание в Азур. 00:15:34.520 --> 00:15:35.580 Вот основная мысль. 00:15:35.740 --> 00:15:37.900 BSIB — это не новая система развертывания. 00:15:38.100 --> 00:15:43.340 Это лучший способ написания тех же шаблонов ARM, использующий тот же движок Azure Resource Manager, 00:15:43.540 --> 00:15:46.260 но на языке, который легко читать и писать человеку. 00:15:46.260 --> 00:15:47.600 Вот вам небольшое задание. 00:15:47.820 --> 00:15:51.540 Создайте файл Main, BSIB, разверните группу ресурсов и запустите развертывание дважды. 00:15:51.640 --> 00:15:53.400 Посмотрите, как это работает оба раза. 00:15:53.580 --> 00:15:57.140 В первый раз он создает ресурс, а во второй — подтверждает, что изменений нет. 00:15:57.260 --> 00:16:01.780 Это тот самый момент озарения, когда понимаешь, что больше никогда не захочешь просто кликать по кнопкам в портале. 00:16:01.920 --> 00:16:02.640 Это фундамент. 00:16:02.820 --> 00:16:07.960 Отсюда можно добавлять учетные записи хранения, виртуальные сети и службы приложений, используя тот же подход. 00:16:08.120 --> 00:16:10.400 Напишите файл, разверните его, запустите снова. 00:16:10.560 --> 00:16:14.020 Этот файл становится вашим единственным источником истины, из которого следует все остальное. 00:16:14.020 --> 00:16:17.900 Если это видео было полезным, поделитесь им с тем, кто все еще кликает мышкой по порталу. 00:16:17.980 --> 00:16:19.000 Они скажут вам спасибо. 00:16:19.260 --> 00:16:21.120 Подписывайтесь на любимой платформе для подкастов. 00:16:21.240 --> 00:16:25.660 А в следующем эпизоде мы углубимся в работу с BSIB и начнем развертывать реальные ресурсы с реальными свойствами.