WEBVTT

00:00:00.000 --> 00:00:03.960
Вітаємо на черговому випуску Microsoft Knowledge Nuggets, тут на М365FM.

00:00:04.080 --> 00:00:05.560
Я ваш ведучий Мірко Пітерс.

00:00:05.680 --> 00:00:08.340
Ви розгортали ресурси Azure, просто клікаючи в порталі.

00:00:08.440 --> 00:00:10.200
Це працює добре, допоки не перестане.

00:00:10.340 --> 00:00:13.140
Тоді вам потрібно повторити це, але ви не можете згадати, що саме обрали.

00:00:13.280 --> 00:00:16.020
Вам потрібно передати роботу колезі, а він не може відтворити ваші дії.

00:00:16.180 --> 00:00:18.380
Контроль версій. Немає чого комітити.

00:00:18.560 --> 00:00:20.420
Це проблема, яку ми сьогодні вирішимо.

00:00:20.620 --> 00:00:23.860
Наприкінці цього епізоду ви зрозумієте, що таке інфраструктура як код,

00:00:23.860 --> 00:00:27.580
чому існує байсеп і як він робить розгортання вежур простішим та надійнішим.

00:00:27.720 --> 00:00:31.740
Ми почнемо з проблеми, потім перейдемо до рішення, а далі розглянемо практичний приклад.

00:00:31.900 --> 00:00:33.680
Беріть каву і занурюємося в тему.

00:00:33.880 --> 00:00:34.920
Проблема порталу.

00:00:35.040 --> 00:00:37.300
Пастка, клікай і розгортай здається швидкою.

00:00:37.440 --> 00:00:40.300
Ви входите в систему, заповнюєте форму, тиснете, створити і готово.

00:00:40.420 --> 00:00:42.980
Але що станеться, коли вам потрібно зробити це знову з тими ж налаштуваннями,

00:00:43.080 --> 00:00:44.280
регіоном та правилами іменування?

00:00:44.280 --> 00:00:47.280
Вам доведеться згадати кожен обраний пункт, і саме тут усе розвалюється.

00:00:47.980 --> 00:00:52.420
Ручне розгортання означає нестабільні результати, людські помилки та відсутність аудиту.

00:00:52.580 --> 00:00:54.140
Ось приклад із реального життя.

00:00:54.300 --> 00:00:57.400
Хтось із вашої команди створює ресурс із дещо іншими налаштуваннями.

00:00:57.500 --> 00:00:59.760
Тепер у вас є два середовища, які не збігаються.

00:00:59.940 --> 00:01:02.520
Одне працює, інше ні, і спробуй розберися чому.

00:01:02.700 --> 00:01:04.560
А ще є проблема з документацією.

00:01:04.840 --> 00:01:07.960
Інфраструктура у вигляді Word документа або, що ще гірше, відео на YouTube,

00:01:07.960 --> 00:01:10.560
записаний півроку тому, коли портал виглядав зовсім інакше.

00:01:10.720 --> 00:01:13.480
Функції переміщуються, меню змінюється, з'являються нові опції.

00:01:13.680 --> 00:01:15.700
Я спілкувався з менеджером продукту з команди Azure Portal,

00:01:15.800 --> 00:01:17.980
і він сказав, що вони випускають нові функції двічі на день.

00:01:18.120 --> 00:01:18.800
Двічі на день.

00:01:18.980 --> 00:01:21.480
Ваш документ у Word стає застарілим ще до того, як ви закінчите його писати.

00:01:21.620 --> 00:01:22.360
Ось у чому річ.

00:01:22.500 --> 00:01:24.020
Клацення в інтерфейсі підходить для навчання.

00:01:24.020 --> 00:01:25.760
Воно не підходить для продуктивного середовища.

00:01:25.840 --> 00:01:27.000
Тож яка є альтернатива?

00:01:27.000 --> 00:01:30.420
Ви пишете файл, який описує те, що вам потрібно, а потім кажете Azure це побудувати.

00:01:30.640 --> 00:01:32.180
Що таке інфраструктура як код?

00:01:32.520 --> 00:01:35.740
Інфраструктура як код означає керування налаштуваннями хмари за допомогою коду,

00:01:35.860 --> 00:01:37.000
а не клаценням у веб-порталі.

00:01:37.120 --> 00:01:38.240
Ось основна ідея.

00:01:38.380 --> 00:01:40.540
Ви створюєте файл, який описує вашу інфраструктуру,

00:01:40.620 --> 00:01:42.240
цей файл зберігається у вашому репозиторії,

00:01:42.240 --> 00:01:45.380
і ви можете використовувати контроль версій, переглядати зміни через Pull Request

00:01:45.380 --> 00:01:47.760
та запускати це знову завтра, щоб отримати той самий результат.

00:01:47.760 --> 00:01:49.940
Тут є ключовий термін – декларативність.

00:01:50.080 --> 00:01:53.320
Це означає, що ви описуєте бажаний результат, а не процес його побудови.

00:01:53.440 --> 00:01:55.580
Ви не кажете Azure, спочатку створіть групу ресурсів,

00:01:55.660 --> 00:01:58.440
потім додайте обліковий запис зберігання, а потім налаштуйте мережу.

00:01:58.580 --> 00:02:02.500
Натомість ви кажете, я хочу групу ресурсів зі сховищем та налаштованою мережею ось так.

00:02:02.500 --> 00:02:04.300
А Azure сама визначає порядок дій.

00:02:04.440 --> 00:02:06.220
Результат називається ідемпотентністю.

00:02:06.360 --> 00:02:08.940
Запустіть раз, запустіть сто разів, і отримаєте однаковий результат.

00:02:09.100 --> 00:02:09.920
У цьому і сила.

00:02:09.920 --> 00:02:12.320
Уявіть, це як креслення проти будівництва вручну.

00:02:12.460 --> 00:02:14.940
Креслення можна повторювати, поширювати та перевіряти.

00:02:15.140 --> 00:02:17.680
Дайте його комусь іншому, і вони збудують точно те саме.

00:02:17.840 --> 00:02:19.480
Зараз це роблять кілька інструментів.

00:02:19.600 --> 00:02:21.760
ARM-шаблони, Bicep, Terraform, Pullumi.

00:02:21.920 --> 00:02:24.300
Усі вони реалізують ту саму концепцію різними способами.

00:02:24.440 --> 00:02:25.600
Це важлива відмінність.

00:02:25.900 --> 00:02:27.440
Інфраструктура як код – це концепція.

00:02:27.580 --> 00:02:29.760
Bicep – це лише один інструмент для її реалізації.

00:02:29.920 --> 00:02:30.880
Але ось у чому річ.

00:02:31.020 --> 00:02:33.780
Azure роками мала власну мову IAC під назвою ARM-шаблони.

00:02:33.780 --> 00:02:36.080
І є причина, чому Microsoft створила нову.

00:02:36.200 --> 00:02:37.560
Проблема ARM-шаблонів.

00:02:37.660 --> 00:02:40.220
ARM-шаблони – це оригінальний формат IAC для Azure.

00:02:40.380 --> 00:02:42.720
Це JSON-файли, і в них є багато переваг.

00:02:42.880 --> 00:02:44.640
Повне охоплення кожного ресурсу Azure

00:02:44.640 --> 00:02:47.700
та той самий механізм розгортання, що використовується всередині.

00:02:47.820 --> 00:02:49.520
Якщо ви можете створити щось на порталі,

00:02:49.600 --> 00:02:51.320
ви можете визначити це в ARM-шаблоні.

00:02:51.420 --> 00:02:52.320
То в чому проблема?

00:02:52.540 --> 00:02:54.880
JSON- чудовий для машин, але жахливий для людей.

00:02:55.060 --> 00:02:56.840
Дозвольте показати, що я маю на увазі.

00:02:57.000 --> 00:02:59.620
Сховище в ARM-шаблоні займає близько 20 рядків коду.

00:02:59.620 --> 00:03:02.100
Те саме сховище в BICEP близько 10 рядків.

00:03:02.220 --> 00:03:04.360
Версія JSON-приблизно вдвічі більша.

00:03:04.480 --> 00:03:05.860
І це лише простий ресурс.

00:03:05.980 --> 00:03:07.620
Уявіть повне розгортання з мережами,

00:03:07.760 --> 00:03:10.100
обчисленнями, базами даних та правилами безпеки.

00:03:10.240 --> 00:03:12.520
ARM-шаблон перетворюється на стіну тексту.

00:03:12.660 --> 00:03:14.800
Типові больові точки цілком передбачувані.

00:03:14.920 --> 00:03:17.260
Пропущені коми, непарні дужки, багатослівна вкладеність,

00:03:17.360 --> 00:03:20.400
через яку важко зрозуміти, де закінчується один ресурс і починається інший.

00:03:20.540 --> 00:03:23.040
Ви витрачаєте більше часу на боротьбу з синтаксисом JSON,

00:03:23.040 --> 00:03:24.600
ніж на визначення інфраструктури.

00:03:24.720 --> 00:03:25.900
А ще є залежності.

00:03:26.040 --> 00:03:29.720
В ERM ви повинні вручну вказувати зворотний апостроф «дапент» з «онзворотний апостроф».

00:03:29.720 --> 00:03:33.120
Якщо ресурсу, а потрібен ресурс, ви повинні прописати це явно.

00:03:33.280 --> 00:03:35.420
Пропустите один, і розгортання не вдасться.

00:03:35.580 --> 00:03:37.720
Успіхів у пошуку того, що саме ви пропустили.

00:03:37.840 --> 00:03:41.360
Якщо ви коли-небудь пробували написати 200-рядковий JSON вручну, це зовсім не весело.

00:03:41.520 --> 00:03:42.220
Навіть трохи.

00:03:42.360 --> 00:03:43.780
Крива навчання дуже стрімка.

00:03:43.960 --> 00:03:46.300
Новим членам команди важко зрозуміти ERM-шаблони.

00:03:46.300 --> 00:03:47.980
Поріг входження дуже високий.

00:03:48.080 --> 00:03:49.480
І що відбувається на практиці?

00:03:49.620 --> 00:03:52.520
Багато команд мають лише одну людину, яка розуміється на ERM-шаблонах.

00:03:52.640 --> 00:03:54.620
Ця людина стає єдиною точкою відмови.

00:03:54.760 --> 00:03:58.480
Вона єдина, хто може змінити розгортання і хто може виправити його, коли щось ламається.

00:03:58.640 --> 00:04:00.080
Це не є сталим рішенням.

00:04:00.200 --> 00:04:04.040
Microsoft почули відгуки і створили Bicep, щоб розв'язати саме ці проблеми.

00:04:04.180 --> 00:04:05.280
Що таке Bicep?

00:04:05.360 --> 00:04:07.040
Отже, що саме таке Bicep?

00:04:07.120 --> 00:04:10.980
Це мова для розгортання ресурсів Azure, яка за своєю суттю є транспейлером.

00:04:10.980 --> 00:04:14.200
Ви пишете на Bicep, а вона компілюється в JSON для ERM.

00:04:14.320 --> 00:04:17.300
Той самий механізм в основі, але набагато чистіший спосіб написання.

00:04:17.460 --> 00:04:19.740
До речі, назва Bicep – це ERM навпаки.

00:04:20.020 --> 00:04:22.340
ERM – маленький внутрішній жарт від Microsoft.

00:04:22.600 --> 00:04:24.580
Але коли бачиш це в дії, усе стає зрозумілим.

00:04:24.700 --> 00:04:26.580
Bicep базується на ERM, а не замінює його.

00:04:26.760 --> 00:04:29.020
Ви отримуєте ту саму потужність, але з простішим синтаксисом.

00:04:29.140 --> 00:04:31.140
Bicep не замінює ERM, він розвиває його.

00:04:31.300 --> 00:04:33.840
Усе, що можна зробити через ERM, можна зробити й через Bicep.

00:04:33.840 --> 00:04:37.180
Будь-який тип ресурсу, будь-яка версія ARRI, будь-яка опція конфігурації – усе тут є.

00:04:37.360 --> 00:04:39.100
Єдина різниця – у способі запису.

00:04:39.340 --> 00:04:40.680
Синтаксис значно чистіший.

00:04:40.840 --> 00:04:43.940
Жодних лапок навколо назв властивостей, ком між ними чи зайвих дужок.

00:04:44.060 --> 00:04:45.180
Це просто простіше.

00:04:45.400 --> 00:04:46.920
Порівняйте дві версії поруч.

00:04:47.100 --> 00:04:50.200
JSON-версія для ERM у сховищі перевантажена зайвим шумом.

00:04:50.360 --> 00:04:52.460
Лапки, коми, дужки, вкладеність.

00:04:52.660 --> 00:04:55.880
Версія на Bicep містить ту саму інформацію, але вона зрозуміла.

00:04:55.880 --> 00:05:00.740
Ви можете поглянути й одразу зрозуміти, що відбувається, не пробираючись крізь шари JSON.

00:05:01.080 --> 00:05:04.140
Одне з важливих покращень – автоматичне виведення залежностей.

00:05:04.300 --> 00:05:06.980
В ERM вам доводиться вручну вказувати Depend Zone.

00:05:07.140 --> 00:05:11.800
А в Bicep, якщо ресурс, а посилається на ресурс, система сама визначає залежність.

00:05:11.960 --> 00:05:13.540
Вам не потрібно писати це вручну.

00:05:13.760 --> 00:05:14.760
Воно просто працює.

00:05:14.880 --> 00:05:16.780
І лише це економить години на налагодження.

00:05:16.940 --> 00:05:18.660
Модулі – ще одна важлива частина.

00:05:18.820 --> 00:05:23.060
Ви можете розбити інфраструктуру на менші, повторно використовувані частини та ділитися ними в проектах.

00:05:23.060 --> 00:05:26.100
Одна команда створює мережевий модуль, а інша використовує його.

00:05:26.280 --> 00:05:28.440
Немає потреби щоразу вигадувати велосипед.

00:05:28.580 --> 00:05:32.460
Параметри та змінні дозволяють визначити вхідні дані один раз і використовувати їх всюди.

00:05:32.640 --> 00:05:35.480
Більше ніякого пошуку та заміни жорстко закодованих значень.

00:05:35.600 --> 00:05:40.160
А інтерполяція рядків дозволяє писати префікси для сховищ замість складних функцій конкатенації.

00:05:40.420 --> 00:05:43.360
Інструментарій – ще одна причина, чому з Bicep так приємно працювати.

00:05:43.360 --> 00:05:48.000
Розширення для VS Code надає IntelliSense, підсвічування синтаксису та перевірку помилок у реальному часі.

00:05:48.140 --> 00:05:50.940
Чесно кажучи, це одне з найкращих мовних розширень у VS Code.

00:05:51.120 --> 00:05:53.460
Ви починаєте друкувати, а воно підказує, що далі.

00:05:53.640 --> 00:05:55.860
Припустилися помилки, і воно одразу сигналізує про це.

00:05:56.020 --> 00:05:59.220
Більше не потрібно чекати на помилку розгортання, щоб дізнатися, що ви пропустили кому.

00:05:59.400 --> 00:06:01.040
Отже, як це виглядає на практиці.

00:06:01.240 --> 00:06:03.560
Давайте подивимося, чим Bicep відрізняється від ARM.

00:06:03.700 --> 00:06:05.920
Bicep проти ARM – у чому ж насправді різниця?

00:06:05.920 --> 00:06:09.640
Давайте поговоримо про те, що насправді змінюється, коли ви пишете на Bicep, а не на ARM.JS.ON.

00:06:09.800 --> 00:06:11.960
Розмір файлу – це одна з очевидних відмінностей.

00:06:12.100 --> 00:06:15.420
Файли Bicep приблизно вдвічі менші за відповідні шаблони ARM.

00:06:15.540 --> 00:06:16.620
Це не перебільшення.

00:06:16.820 --> 00:06:21.180
Ви прибираєте всі лапки, коми, дужки та шаблонний код, і залишається лише опис інфраструктури.

00:06:21.320 --> 00:06:22.880
Половина коду – той самий результат.

00:06:23.100 --> 00:06:24.980
Чи табельність покращується природним чином.

00:06:25.140 --> 00:06:28.040
Менше рядків, чіткіша структура, легше зрозуміти з першого погляду.

00:06:28.040 --> 00:06:31.540
Коли ви відкриваєте файл Bicep, ви можете швидко зрозуміти, що саме розгортається.

00:06:31.700 --> 00:06:36.080
VRM.JS.ON вам доводиться проходити крізь рівні вкладеності, перш ніж знайти реальну конфігурацію ресурсу.

00:06:36.340 --> 00:06:38.220
Залежності – це велика економія часу.

00:06:38.360 --> 00:06:40.420
VRM ви вручну оголошуєте Деппендсон.

00:06:40.580 --> 00:06:42.680
Пропустите одну, і розгортання не вдасться.

00:06:42.800 --> 00:06:46.780
У Bicep, якщо ресурси і посилається на ресурс B, система обробляє це автоматично.

00:06:47.020 --> 00:06:49.600
Вона додає залежність під час компіляції VRM.JS.ON.

00:06:49.780 --> 00:06:51.640
Ви про це не думаєте, воно просто працює.

00:06:58.040 --> 00:07:01.220
Окрімі файли, складні посилання, важко версіонувати.

00:07:01.380 --> 00:07:04.740
Bicep має модулі, які чистіші, версіоновані та багаторазові.

00:07:04.860 --> 00:07:08.920
Ви визначаєте модуль один раз, публікуєте його в реєстрі та посилаєтесь на нього звідусіль.

00:07:09.040 --> 00:07:11.600
Той самий модуль та сама конфігурація кожного разу.

00:07:11.780 --> 00:07:13.500
Сам процес розгортання ідентичний.

00:07:13.680 --> 00:07:16.980
Bicep компілюється в VRM.JS.ON, а потім ежур разосменеджа розгортає його.

00:07:17.140 --> 00:07:18.820
Той самий рушій, той самий конвейер.

00:07:18.960 --> 00:07:22.600
Вам не потрібно змінювати процес розгортання, ви лише змінюєте спосіб написання шаблонів.

00:07:22.600 --> 00:07:26.860
WhatIf – це функція, яку технічно має ARM, але Bicep робить її набагато доступнішою.

00:07:27.000 --> 00:07:31.460
Ви можете переглянути зміни перед розгортанням і точно побачити, що буде створено, змінено або видалено.

00:07:31.640 --> 00:07:33.720
Жодних сюрпризів, жодних випадкових видалень.

00:07:33.860 --> 00:07:36.940
Ви запускаєте WhatIf, перевіряєте результат і, якщо все правильно, розгортаєте.

00:07:37.060 --> 00:07:39.140
Крива навчання – це те, де Bicep виділяється.

00:07:39.300 --> 00:07:41.460
ARM.JS.ON припускає, що ви знаєте, що робите.

00:07:41.620 --> 00:07:43.200
Він розроблений для машин, а не для людей.

00:07:43.400 --> 00:07:44.880
Bicep розроблений для початківців.

00:07:44.880 --> 00:07:47.160
Інтуїтивно зрозумілий синтаксис інструментарій, що підказує вам.

00:07:47.300 --> 00:07:49.800
Ви можете вивчити його за півдня і стати продуктивними до кінця тижня.

00:07:49.920 --> 00:07:52.700
Microsoft зробила Bicep рекомендуваним способом написання шаблонів.

00:07:52.860 --> 00:07:55.460
Усі нові функції та покращення спрямовані насамперед на Bicep.

00:07:55.620 --> 00:07:59.420
Шаблони ARM все ще працюють і нікуди не зникають, але вам, мабуть, не варто писати нові.

00:07:59.540 --> 00:08:02.600
Якщо ви починаєте новий проект сьогодні, Bicep – це найкращий вибір.

00:08:02.700 --> 00:08:05.060
Три рядки Bicep для розгортання групи ресурсів.

00:08:05.220 --> 00:08:06.080
Лише три рядки.

00:08:06.080 --> 00:08:08.780
Еквівалентний ARMJS-ОН – це близько 15 рядків.

00:08:08.900 --> 00:08:12.320
Однаковий результат – однакове розгортання, але одне читабельне, а інше – лише шум.

00:08:12.440 --> 00:08:14.460
Тепер ви можете запитати, а як щодо Терафом?

00:08:14.600 --> 00:08:16.080
Що мені вивчати, Bicep чи Терафом?

00:08:16.320 --> 00:08:17.160
Подвійний апостроф.

00:08:17.280 --> 00:08:19.380
Bicep чи Терафом – що варто використовувати?

00:08:19.560 --> 00:08:21.640
Вітаємо знову на Microsoft Knowledge Nuggets.

00:08:21.820 --> 00:08:24.660
Я Мірко Петерс, і сьогодні ми розберемо питання, яке постійно виникає.

00:08:24.800 --> 00:08:25.840
Bicep чи Терафом?

00:08:26.000 --> 00:08:27.060
Давайте розберемося.

00:08:27.060 --> 00:08:28.780
Терафом працює з багатьма хмарами.

00:08:36.080 --> 00:08:40.580
Якщо ви працюєте з кількома хмарами, Терафом – це ваш вибір.

00:08:40.720 --> 00:08:45.000
Ви вчите одну мову, один інструмент, один робочий процес, і це працює всюди.

00:08:45.160 --> 00:08:48.760
Але якщо ви працюєте переважно з Azure, Bicep має реальні переваги.

00:08:48.900 --> 00:08:49.800
Ось перша з них.

00:08:49.980 --> 00:08:51.900
Немає файлу стану, яким треба керувати.

00:08:52.080 --> 00:08:55.840
Терафом зберігає файл стану, який відстежує розгортання, і цей файл критично важливий.

00:08:55.840 --> 00:08:59.280
Якщо він пошкодиться або синхронізація порушиться, у вас виникнуть серйозні проблеми.

00:08:59.280 --> 00:09:02.580
Ви повинні надійно його зберігати, робити резервні копії та керувати доступом.

00:09:02.740 --> 00:09:07.360
Bicep звертається напряму до Azure Razos Manager, перевіряючи, що вже існує, і визначаючи різницю.

00:09:07.500 --> 00:09:11.280
Відсутність файлу стану означає відсутність проблем із синхронізацією та ризику пошкодження.

00:09:11.460 --> 00:09:13.440
Друга перевага – підтримка з першого дня.

00:09:13.620 --> 00:09:17.940
Коли Microsoft випускає нову функцію Azure, Bicep підтримує її негайно того ж дня.

00:09:17.940 --> 00:09:22.620
Терафом має чекати на оновлення провайдера, що іноді буває швидко, а іноді займає тижні.

00:09:22.620 --> 00:09:26.280
Якщо вам потрібно використати нову функцію негайно, Bicep – єдиний варіант.

00:09:26.440 --> 00:09:28.420
По-третє, він створений командою Azure.

00:09:28.660 --> 00:09:33.380
Інструменти IntelliSense, повідомлення про помилки – усе розроблено з урахуванням того, як працює Azure.

00:09:33.540 --> 00:09:37.980
Коли ви пишете на Bicep, ви використовуєте мову, яка розуміє ресурси Azure на рівні архітектури.

00:09:38.120 --> 00:09:41.960
Він знає, які властивості обов'язкові, які значення валідні та які існують залежності.

00:09:41.960 --> 00:09:44.900
Таку глибоку інтеграцію важко відтворити стороннім інструментом.

00:09:45.020 --> 00:09:46.760
Ви також можете використовувати обидва.

00:09:46.760 --> 00:09:51.220
Багато організацій використовують Bicep для платформ і посадкових зон, а Терафом – для мультихмарних робочих навантажень.

00:09:51.360 --> 00:09:52.780
Вони не є взаємовиключними.

00:09:52.920 --> 00:09:55.380
Ви можете обрати правильний інструмент для кожного завдання.

00:09:55.520 --> 00:09:56.640
Чесна відповідь така.

00:09:56.800 --> 00:09:59.380
Для вивчення саме Azure у Bicep менше рухомих частин.

00:09:59.520 --> 00:10:01.540
Це простіший шлях, коли ви тільки починаєте.

00:10:01.700 --> 00:10:04.700
Вам не потрібно розбиратися у файлах стану, провайдерах чи налаштуваннях бекенду.

00:10:04.700 --> 00:10:07.940
Ви встановлюєте Azure CLI, відкриваєте VS Code і починаєте писати.

00:10:08.080 --> 00:10:08.940
Досить теорії.

00:10:08.940 --> 00:10:11.640
Давайте поговоримо про те, що насправді потрібно для старту.

00:10:11.740 --> 00:10:12.700
Початок роботи.

00:10:12.880 --> 00:10:14.180
Що вам насправді потрібно?

00:10:14.320 --> 00:10:16.120
Для початку вам знадобляться дві речі.

00:10:16.240 --> 00:10:18.660
Azure CLI та Bicep-роширення для VS Code.

00:10:18.840 --> 00:10:19.280
Це все.

00:10:19.480 --> 00:10:22.540
Не потрібно встановлювати окремий Bicep CLI чи налаштовувати додаткові інструменти.

00:10:22.660 --> 00:10:24.580
Azure CLI вже містить вбудований Bicep.

00:10:24.700 --> 00:10:26.440
Встановлення Azure CLI доволі просте.

00:10:26.440 --> 00:10:27.940
Перейдіть до Microsoft Docs.

00:10:28.060 --> 00:10:30.480
Знайдіть сторінку встановлення для вашої операційної системи.

00:10:30.580 --> 00:10:32.440
Якщо ви на Mac, це лише одна команда.

00:10:32.600 --> 00:10:33.960
Brew Install Azure CLI.

00:10:33.960 --> 00:10:35.760
Для Windows є інсталятор MSI.

00:10:35.940 --> 00:10:37.600
Завантажте, запустіть і готово.

00:10:37.720 --> 00:10:39.980
Це також працює на Linux через ваш менеджер пакетів.

00:10:40.100 --> 00:10:43.780
Після встановлення запустіть AZ-версион, щоб переконатися, що все працює.

00:10:43.940 --> 00:10:46.860
Ви побачите список версій Azure CLI та Bicep.

00:10:46.980 --> 00:10:51.460
Тепер відкрийте VS Code, перейдіть до панелі розширень ліворуч і знайдіть Bicep.

00:10:51.460 --> 00:10:54.700
Встановіть версію від Microsoft, не сторонню, а офіційну.

00:10:54.840 --> 00:10:56.660
Це розширення вам дійсно потрібне.

00:10:56.800 --> 00:11:00.040
Воно надає IntelliSense, що підказує властивості ресурсів під час введення,

00:11:00.040 --> 00:11:03.780
підсвічує синтаксис для швидкого виявлення помилок та перевіряє їх у реальному часі.

00:11:03.920 --> 00:11:07.600
Ви побачите червоні хвилясті лінії під помилковим кодом ще до спроби розгортання.

00:11:07.780 --> 00:11:10.380
Чесно кажучи, це одне з найкращих мовних розширень у VS Code

00:11:10.380 --> 00:11:12.760
і головна причина, чому з Bicep так приємно працювати.

00:11:12.920 --> 00:11:15.500
Тепер створіть новий файл і назвіть його main – Bicep.

00:11:15.500 --> 00:11:18.500
Це Bicep розширення повідомляє VS Code про активацію інструментів.

00:11:18.620 --> 00:11:20.460
Без нього ви просто пишете звичайний текст.

00:11:20.640 --> 00:11:22.920
З ним ви отримуєте повний функціонал інструментарію.

00:11:23.060 --> 00:11:24.080
Ось швидкий приклад.

00:11:30.040 --> 00:11:33.600
Це все лише три рядки.

00:11:33.740 --> 00:11:38.120
Порівняйте це з еквівалентом ARM.js.on, який потребує близько 15 рядків з дужками та лапками.

00:11:38.300 --> 00:11:40.500
Для розгортання використовується Azure CLI.

00:11:40.640 --> 00:11:44.960
Оскільки розгортання відбувається на рівні підписки, команда виглядає як az-deployment-sub-create.

00:11:44.960 --> 00:11:48.700
Ви передаєте розташування для метаданих розгортання та вказуєте шлях до вашого Bicep-файлу.

00:11:48.820 --> 00:11:51.540
Це спосіб через командний рядок, але є також і керований процес.

00:11:51.700 --> 00:11:55.520
У VS Code клацніть правою кнопкою миші на Bicep-файл і виберіть Deploy Bicep-файл.

00:11:55.520 --> 00:11:57.300
Він проведе вас через весь процес.

00:11:57.480 --> 00:12:01.980
Вас попросять назвати розгортання, обрати підписку, створити або вибрати групу ресурсів,

00:12:02.060 --> 00:12:03.880
а також запитають про файл параметрів.

00:12:04.020 --> 00:12:06.180
Ви відповідаєте «Ні» і розгортання починається.

00:12:06.380 --> 00:12:08.100
Результат з'явиться на вашому порталі Azure.

00:12:08.100 --> 00:12:11.300
Це те саме, що клацати на порталі, але тепер у вас є файл, який можна використовувати повторно.

00:12:11.420 --> 00:12:15.000
Ви можете зафіксувати його у своєму репозиторії, поділитися з командою та запустити знову завтра.

00:12:15.160 --> 00:12:16.040
А ось і магія.

00:12:16.260 --> 00:12:19.300
Запустіть те саме розгортання знову і подивіться, що станеться.

00:12:25.520 --> 00:12:27.800
Це саме те, що дає вам ідемпотентність.

00:12:27.920 --> 00:12:32.540
Першого разу ви запускаєте байсеп-файл, і він створює групу ресурсів, але вдруге нічого не відбувається.

00:12:32.740 --> 00:12:35.000
Жодних помилок, жодних дублікатів, нічого.

00:12:35.200 --> 00:12:39.620
Байсеп перевіряє, що вже є вежур, порівнює з вашим запитом і каже, що змінювати нічого.

00:12:39.620 --> 00:12:43.980
Він не намагався створити нову групу ресурсів і не видав помилку про те, що вона вже існує.

00:12:44.100 --> 00:12:46.980
Він просто підтвердив, що поточний стан відповідає бажаному.

00:12:46.980 --> 00:12:49.820
Уявіть це як виконання GitStatus у чистому репозиторії.

00:12:49.960 --> 00:12:51.000
Там нічого робити.

00:12:51.240 --> 00:12:52.920
Все вже саме так, як має бути.

00:12:53.100 --> 00:12:54.980
Це і є сила інфраструктури як коду.

00:12:55.160 --> 00:12:58.580
Ви можете запускати розгортання знову і знову і щоразу отримувати той самий результат.

00:12:58.800 --> 00:13:00.820
Жодних сюрпризів, жодного суву конфігурації.

00:13:00.820 --> 00:13:03.500
Ви точно знаєте, що розгорнуто, бо так написано у файлі.

00:13:03.620 --> 00:13:05.680
Файл стає вашим єдиним джерелом істини.

00:13:05.840 --> 00:13:09.380
Вам більше не треба думати, чи не забули ви налаштування, стикатися з проблемою,

00:13:09.380 --> 00:13:13.160
на моєму комп'ютері працює, або шукати в порталі Azure, чи хтось щось змінив.

00:13:13.280 --> 00:13:14.760
Файл каже вам, що там є.

00:13:14.940 --> 00:13:17.920
Якщо хочете щось змінити, ви змінюєте файл і розгортаєте знову.

00:13:18.040 --> 00:13:22.000
Якщо хочете перевірити, запустіть розгортання ще раз, і воно підтвердить, що все збігається.

00:13:22.000 --> 00:13:24.700
Ось як ви будуєте впевненість у своїй інфраструктурі.

00:13:24.820 --> 00:13:26.400
Файл – це джерело істини.

00:13:26.560 --> 00:13:30.960
Не ваша пам'ять, не документ Word, не відео на YouTube піврічної давнини, а файл.

00:13:31.080 --> 00:13:33.800
Отже, DeBicep вписується в загальну картину Azure.

00:13:33.800 --> 00:13:36.540
Загальна картина, де DeBicep займає своє місце.

00:13:36.740 --> 00:13:39.440
DeBicep живе всередині екосистеми Azure Razos Manager.

00:13:39.700 --> 00:13:40.900
Це не окремий інструмент.

00:13:41.220 --> 00:13:44.800
Багато хто так думає, але насправді це просто кращий спосіб писати ERM-шаблони.

00:13:44.800 --> 00:13:48.760
Технічно це все ще ERM, той самий механізм розгортання, той самий ARRI – все те саме.

00:13:48.920 --> 00:13:50.720
Єдина різниця – це спосіб написання.

00:13:50.880 --> 00:13:54.740
І оскільки Bicep компілюється в ERM, усе, що працює з ERM, працює із Bicep.

00:13:54.900 --> 00:13:57.660
Azure Policy забезпечує відповідність ваших розгортань вимогам.

00:13:57.660 --> 00:13:59.960
RBAC контролює, хто і що може розгортати.

00:14:00.120 --> 00:14:02.400
Cost Management відстежує витрати на ваші ресурси.

00:14:02.540 --> 00:14:05.920
Azure DevOps та GitHub Actions розгортають ваші Bicep-файли через конвейери.

00:14:05.920 --> 00:14:09.140
Все працює ідеально, оскільки Bicep створює стандартний JSON для ERM.

00:14:09.260 --> 00:14:11.080
Ви нічого не втрачаєте, переходячи на нього.

00:14:11.260 --> 00:14:12.960
Насправді, ви отримуєте ясність.

00:14:13.100 --> 00:14:15.760
Microsoft побудувала цілу екосистему навколо Bicep.

00:14:15.820 --> 00:14:19.560
Azure Verified Modules або AVM – це підібрана бібліотека модулів Bicep та Terraform,

00:14:19.680 --> 00:14:21.200
що відповідають найкращим практикам.

00:14:21.340 --> 00:14:22.960
Вам не потрібно писати все з нуля.

00:14:22.960 --> 00:14:28.420
Ви можете використовувати готові модулі для типових завдань, як-от віртуальні мережі, облікові записи зберігання та служби додатків.

00:14:28.540 --> 00:14:32.200
Вони протестувані, підтримуються та узгоджені з концепцією Well-Architected Framework.

00:14:32.340 --> 00:14:37.020
Cloud Adoption Framework містить еталенні реалізації Bicep для стандартизованих корпоративних архітектур.

00:14:37.140 --> 00:14:40.360
Якщо ви створюєте цільову зону Landing Zone, для цього є шаблон Bicep.

00:14:40.520 --> 00:14:43.920
Стеки розгортання забезпечують керування життєвим циклом для груп ресурсів.

00:14:43.920 --> 00:14:48.800
Ви можете розгорнути стек, і якщо видалите ресурс із файлу Bicep, стек може видалити його за вас.

00:14:48.900 --> 00:14:51.120
Або захистити його від випадкового видалення.

00:14:51.380 --> 00:14:52.180
Вирішувати вам.

00:14:52.340 --> 00:14:57.760
Екосистема продовжує зростати завдяки новим модулям, кращим інструментам та глибшій інтеграції зі штучним інтелектом і Дітхаб Коупайлот.

00:14:57.900 --> 00:15:02.340
Ви можете описати бажаний результат простою мовою, а Коупайлот згенерує для вас код Bicep.

00:15:02.440 --> 00:15:06.440
Майкрософт продовжує інвестувати в Bicep як основний інструмент для роботи з ажур.

00:15:06.440 --> 00:15:09.020
Тож нові функції впроваджуються насамперед у Bicep.

00:15:09.120 --> 00:15:12.200
Шаблони ERM все ще працюють, але інновації відбуваються саме в Bicep.

00:15:12.300 --> 00:15:13.560
Отже, головний висновок.

00:15:13.700 --> 00:15:17.440
Якщо ви працюєте вежур, Bicep – це природний наступний крок після клікання в порталі.

00:15:17.560 --> 00:15:20.400
Вам не потрібно вивчати Терафом або опановувати ERM.JS.ОН.

00:15:20.560 --> 00:15:26.120
Ви встановлюєте дві речі, пишете кілька рядків коду і розгортаєте інфраструктуру, яка є відтворюваною, версійною та надійною.

00:15:26.120 --> 00:15:29.400
Дозвольте залишити вас із чимось практичним, що ви можете зробити вже сьогодні.

00:15:29.520 --> 00:15:34.440
Отже, тепер ви знаєте, що таке інфраструктура як код, навіщо потрібен Bicep і як він спрощує розгортання вежур.

00:15:34.540 --> 00:15:35.560
Ось головна думка.

00:15:35.740 --> 00:15:37.880
Bicep – це не окрема система розгортання.

00:15:38.040 --> 00:15:46.300
Це кращий спосіб написання тих самих шаблонів ERM, використовуючи той самий механізм і Azure Razos менеджа, але мовою, яку люди можуть читати і писати.

00:15:46.480 --> 00:15:47.600
Ось завдання для вас.

00:15:47.780 --> 00:15:51.420
Створіть файл мейн Bicep, розгорніть групу ресурсів і запустіть розгортання двічі.

00:15:51.420 --> 00:15:53.440
Подивіться, як це працює обидва рази.

00:15:53.540 --> 00:15:57.140
Першого разу він створює ресурс, а другого – підтверджує, що нічого не змінилося.

00:15:57.280 --> 00:16:01.760
Це той самий момент усвідомлення, коли ви розумієте, що більше ніколи не повернетеся до клікання в порталі.

00:16:01.880 --> 00:16:02.720
Це основа.

00:16:02.880 --> 00:16:07.960
Звідси ви можете додавати облікові записи зберігання, віртуальні мережі та служби додатків за тим самим шаблоном.

00:16:08.160 --> 00:16:10.620
Напишіть файл, розгорніть його, запустіть знову.

00:16:10.620 --> 00:16:13.920
Цей файл стає вашим джерелом істини, а все інше випливає з нього.

00:16:13.920 --> 00:16:17.680
Якщо це було корисно, поділіться з тими, хто все ще клікає в порталі.

00:16:17.800 --> 00:16:19.020
Вони будуть вам вдячні.

00:16:19.140 --> 00:16:25.640
Підписуйтесь на вашу улюблену подкаст-платформу і в наступному епізоді ми глибше розглянемо байсеп, розгортаючи реальні ресурси з реальними властивостями.