Вітаємо на черговому випуску Microsoft Knowledge Nuggets, тут на М365FM. Я ваш ведучий Мірко Пітерс. Ви розгортали ресурси Azure, просто клікаючи в порталі. Це працює добре, допоки не перестане. Тоді вам потрібно повторити це, але ви не можете згадати, що саме обрали. Вам потрібно передати роботу колезі, а він не може відтворити ваші дії. Контроль версій. Немає чого комітити. Це проблема, яку ми сьогодні вирішимо. Наприкінці цього епізоду ви зрозумієте, що таке інфраструктура як код, чому існує байсеп і як він робить розгортання вежур простішим та надійнішим. Ми почнемо з проблеми, потім перейдемо до рішення, а далі розглянемо практичний приклад. Беріть каву і занурюємося в тему. Проблема порталу. Пастка, клікай і розгортай здається швидкою. Ви входите в систему, заповнюєте форму, тиснете, створити і готово. Але що станеться, коли вам потрібно зробити це знову з тими ж налаштуваннями, регіоном та правилами іменування?

Вам доведеться згадати кожен обраний пункт, і саме тут усе розвалюється. Ручне розгортання означає нестабільні результати, людські помилки та відсутність аудиту. Ось приклад із реального життя. Хтось із вашої команди створює ресурс із дещо іншими налаштуваннями. Тепер у вас є два середовища, які не збігаються. Одне працює, інше ні, і спробуй розберися чому. А ще є проблема з документацією. Інфраструктура у вигляді Word документа або, що ще гірше, відео на YouTube, записаний півроку тому, коли портал виглядав зовсім інакше. Функції переміщуються, меню змінюється, з'являються нові опції. Я спілкувався з менеджером продукту з команди Azure Portal, і він сказав, що вони випускають нові функції двічі на день. Двічі на день. Ваш документ у Word стає застарілим ще до того, як ви закінчите його писати. Ось у чому річ. Клацення в інтерфейсі підходить для навчання. Воно не підходить для продуктивного середовища.

Тож яка є альтернатива? Ви пишете файл, який описує те, що вам потрібно, а потім кажете Azure це побудувати. Що таке інфраструктура як код? Інфраструктура як код означає керування налаштуваннями хмари за допомогою коду, а не клаценням у веб-порталі. Ось основна ідея. Ви створюєте файл, який описує вашу інфраструктуру, цей файл зберігається у вашому репозиторії, і ви можете використовувати контроль версій, переглядати зміни через Pull Request та запускати це знову завтра, щоб отримати той самий результат. Тут є ключовий термін – декларативність. Це означає, що ви описуєте бажаний результат, а не процес його побудови. Ви не кажете Azure, спочатку створіть групу ресурсів, потім додайте обліковий запис зберігання, а потім налаштуйте мережу. Натомість ви кажете, я хочу групу ресурсів зі сховищем та налаштованою мережею ось так. А Azure сама визначає порядок дій. Результат називається ідемпотентністю.

Запустіть раз, запустіть сто разів, і отримаєте однаковий результат. У цьому і сила. Уявіть, це як креслення проти будівництва вручну. Креслення можна повторювати, поширювати та перевіряти. Дайте його комусь іншому, і вони збудують точно те саме. Зараз це роблять кілька інструментів. ARM-шаблони, Bicep, Terraform, Pullumi. Усі вони реалізують ту саму концепцію різними способами. Це важлива відмінність. Інфраструктура як код – це концепція. Bicep – це лише один інструмент для її реалізації. Але ось у чому річ. Azure роками мала власну мову IAC під назвою ARM-шаблони. І є причина, чому Microsoft створила нову. Проблема ARM-шаблонів. ARM-шаблони – це оригінальний формат IAC для Azure. Це JSON-файли, і в них є багато переваг. Повне охоплення кожного ресурсу Azure та той самий механізм розгортання, що використовується всередині. Якщо ви можете створити щось на порталі, ви можете визначити це в ARM-шаблоні.

То в чому проблема? JSON- чудовий для машин, але жахливий для людей. Дозвольте показати, що я маю на увазі. Сховище в ARM-шаблоні займає близько 20 рядків коду. Те саме сховище в BICEP близько 10 рядків. Версія JSON-приблизно вдвічі більша. І це лише простий ресурс. Уявіть повне розгортання з мережами, обчисленнями, базами даних та правилами безпеки. ARM-шаблон перетворюється на стіну тексту. Типові больові точки цілком передбачувані. Пропущені коми, непарні дужки, багатослівна вкладеність, через яку важко зрозуміти, де закінчується один ресурс і починається інший. Ви витрачаєте більше часу на боротьбу з синтаксисом JSON, ніж на визначення інфраструктури. А ще є залежності. В ERM ви повинні вручну вказувати зворотний апостроф «дапент» з «онзворотний апостроф». Якщо ресурсу, а потрібен ресурс, ви повинні прописати це явно. Пропустите один, і розгортання не вдасться. Успіхів у пошуку того, що саме ви пропустили.

Якщо ви коли-небудь пробували написати 200-рядковий JSON вручну, це зовсім не весело. Навіть трохи. Крива навчання дуже стрімка. Новим членам команди важко зрозуміти ERM-шаблони. Поріг входження дуже високий. І що відбувається на практиці? Багато команд мають лише одну людину, яка розуміється на ERM-шаблонах. Ця людина стає єдиною точкою відмови. Вона єдина, хто може змінити розгортання і хто може виправити його, коли щось ламається. Це не є сталим рішенням. Microsoft почули відгуки і створили Bicep, щоб розв'язати саме ці проблеми. Що таке Bicep? Отже, що саме таке Bicep? Це мова для розгортання ресурсів Azure, яка за своєю суттю є транспейлером. Ви пишете на Bicep, а вона компілюється в JSON для ERM. Той самий механізм в основі, але набагато чистіший спосіб написання. До речі, назва Bicep – це ERM навпаки. ERM – маленький внутрішній жарт від Microsoft. Але коли бачиш це в дії, усе стає зрозумілим.

Bicep базується на ERM, а не замінює його. Ви отримуєте ту саму потужність, але з простішим синтаксисом. Bicep не замінює ERM, він розвиває його. Усе, що можна зробити через ERM, можна зробити й через Bicep. Будь-який тип ресурсу, будь-яка версія ARRI, будь-яка опція конфігурації – усе тут є. Єдина різниця – у способі запису. Синтаксис значно чистіший. Жодних лапок навколо назв властивостей, ком між ними чи зайвих дужок. Це просто простіше. Порівняйте дві версії поруч. JSON-версія для ERM у сховищі перевантажена зайвим шумом. Лапки, коми, дужки, вкладеність. Версія на Bicep містить ту саму інформацію, але вона зрозуміла. Ви можете поглянути й одразу зрозуміти, що відбувається, не пробираючись крізь шари JSON. Одне з важливих покращень – автоматичне виведення залежностей. В ERM вам доводиться вручну вказувати Depend Zone. А в Bicep, якщо ресурс, а посилається на ресурс, система сама визначає залежність.

Вам не потрібно писати це вручну. Воно просто працює. І лише це економить години на налагодження. Модулі – ще одна важлива частина. Ви можете розбити інфраструктуру на менші, повторно використовувані частини та ділитися ними в проектах. Одна команда створює мережевий модуль, а інша використовує його. Немає потреби щоразу вигадувати велосипед. Параметри та змінні дозволяють визначити вхідні дані один раз і використовувати їх всюди. Більше ніякого пошуку та заміни жорстко закодованих значень. А інтерполяція рядків дозволяє писати префікси для сховищ замість складних функцій конкатенації. Інструментарій – ще одна причина, чому з Bicep так приємно працювати. Розширення для VS Code надає IntelliSense, підсвічування синтаксису та перевірку помилок у реальному часі. Чесно кажучи, це одне з найкращих мовних розширень у VS Code. Ви починаєте друкувати, а воно підказує, що далі. Припустилися помилки, і воно одразу сигналізує про це.

Більше не потрібно чекати на помилку розгортання, щоб дізнатися, що ви пропустили кому. Отже, як це виглядає на практиці. Давайте подивимося, чим Bicep відрізняється від ARM. Bicep проти ARM – у чому ж насправді різниця? Давайте поговоримо про те, що насправді змінюється, коли ви пишете на Bicep, а не на ARM.JS.ON. Розмір файлу – це одна з очевидних відмінностей. Файли Bicep приблизно вдвічі менші за відповідні шаблони ARM. Це не перебільшення. Ви прибираєте всі лапки, коми, дужки та шаблонний код, і залишається лише опис інфраструктури. Половина коду – той самий результат. Чи табельність покращується природним чином. Менше рядків, чіткіша структура, легше зрозуміти з першого погляду. Коли ви відкриваєте файл Bicep, ви можете швидко зрозуміти, що саме розгортається. VRM.JS.ON вам доводиться проходити крізь рівні вкладеності, перш ніж знайти реальну конфігурацію ресурсу. Залежності – це велика економія часу.

VRM ви вручну оголошуєте Деппендсон. Пропустите одну, і розгортання не вдасться. У Bicep, якщо ресурси і посилається на ресурс B, система обробляє це автоматично. Вона додає залежність під час компіляції VRM.JS.ON. Ви про це не думаєте, воно просто працює.

Окрімі файли, складні посилання, важко версіонувати. Bicep має модулі, які чистіші, версіоновані та багаторазові. Ви визначаєте модуль один раз, публікуєте його в реєстрі та посилаєтесь на нього звідусіль. Той самий модуль та сама конфігурація кожного разу. Сам процес розгортання ідентичний. Bicep компілюється в VRM.JS.ON, а потім ежур разосменеджа розгортає його. Той самий рушій, той самий конвейер. Вам не потрібно змінювати процес розгортання, ви лише змінюєте спосіб написання шаблонів. WhatIf – це функція, яку технічно має ARM, але Bicep робить її набагато доступнішою. Ви можете переглянути зміни перед розгортанням і точно побачити, що буде створено, змінено або видалено. Жодних сюрпризів, жодних випадкових видалень. Ви запускаєте WhatIf, перевіряєте результат і, якщо все правильно, розгортаєте. Крива навчання – це те, де Bicep виділяється. ARM.JS.ON припускає, що ви знаєте, що робите.

Він розроблений для машин, а не для людей. Bicep розроблений для початківців. Інтуїтивно зрозумілий синтаксис інструментарій, що підказує вам. Ви можете вивчити його за півдня і стати продуктивними до кінця тижня. Microsoft зробила Bicep рекомендуваним способом написання шаблонів. Усі нові функції та покращення спрямовані насамперед на Bicep. Шаблони ARM все ще працюють і нікуди не зникають, але вам, мабуть, не варто писати нові. Якщо ви починаєте новий проект сьогодні, Bicep – це найкращий вибір. Три рядки Bicep для розгортання групи ресурсів. Лише три рядки. Еквівалентний ARMJS-ОН – це близько 15 рядків. Однаковий результат – однакове розгортання, але одне читабельне, а інше – лише шум. Тепер ви можете запитати, а як щодо Терафом? Що мені вивчати, Bicep чи Терафом? Подвійний апостроф. Bicep чи Терафом – що варто використовувати? Вітаємо знову на Microsoft Knowledge Nuggets. Я Мірко Петерс, і сьогодні ми розберемо питання, яке постійно виникає.

Bicep чи Терафом? Давайте розберемося. Терафом працює з багатьма хмарами.

Якщо ви працюєте з кількома хмарами, Терафом – це ваш вибір. Ви вчите одну мову, один інструмент, один робочий процес, і це працює всюди. Але якщо ви працюєте переважно з Azure, Bicep має реальні переваги. Ось перша з них. Немає файлу стану, яким треба керувати. Терафом зберігає файл стану, який відстежує розгортання, і цей файл критично важливий. Якщо він пошкодиться або синхронізація порушиться, у вас виникнуть серйозні проблеми. Ви повинні надійно його зберігати, робити резервні копії та керувати доступом. Bicep звертається напряму до Azure Razos Manager, перевіряючи, що вже існує, і визначаючи різницю. Відсутність файлу стану означає відсутність проблем із синхронізацією та ризику пошкодження. Друга перевага – підтримка з першого дня. Коли Microsoft випускає нову функцію Azure, Bicep підтримує її негайно того ж дня. Терафом має чекати на оновлення провайдера, що іноді буває швидко, а іноді займає тижні.

Якщо вам потрібно використати нову функцію негайно, Bicep – єдиний варіант. По-третє, він створений командою Azure. Інструменти IntelliSense, повідомлення про помилки – усе розроблено з урахуванням того, як працює Azure. Коли ви пишете на Bicep, ви використовуєте мову, яка розуміє ресурси Azure на рівні архітектури. Він знає, які властивості обов'язкові, які значення валідні та які існують залежності. Таку глибоку інтеграцію важко відтворити стороннім інструментом. Ви також можете використовувати обидва. Багато організацій використовують Bicep для платформ і посадкових зон, а Терафом – для мультихмарних робочих навантажень. Вони не є взаємовиключними. Ви можете обрати правильний інструмент для кожного завдання. Чесна відповідь така. Для вивчення саме Azure у Bicep менше рухомих частин. Це простіший шлях, коли ви тільки починаєте. Вам не потрібно розбиратися у файлах стану, провайдерах чи налаштуваннях бекенду.

Ви встановлюєте Azure CLI, відкриваєте VS Code і починаєте писати. Досить теорії. Давайте поговоримо про те, що насправді потрібно для старту. Початок роботи. Що вам насправді потрібно? Для початку вам знадобляться дві речі. Azure CLI та Bicep-роширення для VS Code. Це все. Не потрібно встановлювати окремий Bicep CLI чи налаштовувати додаткові інструменти. Azure CLI вже містить вбудований Bicep. Встановлення Azure CLI доволі просте. Перейдіть до Microsoft Docs. Знайдіть сторінку встановлення для вашої операційної системи. Якщо ви на Mac, це лише одна команда. Brew Install Azure CLI. Для Windows є інсталятор MSI. Завантажте, запустіть і готово. Це також працює на Linux через ваш менеджер пакетів. Після встановлення запустіть AZ-версион, щоб переконатися, що все працює. Ви побачите список версій Azure CLI та Bicep. Тепер відкрийте VS Code, перейдіть до панелі розширень ліворуч і знайдіть Bicep.

Встановіть версію від Microsoft, не сторонню, а офіційну. Це розширення вам дійсно потрібне. Воно надає IntelliSense, що підказує властивості ресурсів під час введення, підсвічує синтаксис для швидкого виявлення помилок та перевіряє їх у реальному часі. Ви побачите червоні хвилясті лінії під помилковим кодом ще до спроби розгортання. Чесно кажучи, це одне з найкращих мовних розширень у VS Code і головна причина, чому з Bicep так приємно працювати. Тепер створіть новий файл і назвіть його main – Bicep. Це Bicep розширення повідомляє VS Code про активацію інструментів. Без нього ви просто пишете звичайний текст. З ним ви отримуєте повний функціонал інструментарію. Ось швидкий приклад.

Це все лише три рядки. Порівняйте це з еквівалентом ARM.js.on, який потребує близько 15 рядків з дужками та лапками. Для розгортання використовується Azure CLI. Оскільки розгортання відбувається на рівні підписки, команда виглядає як az-deployment-sub-create. Ви передаєте розташування для метаданих розгортання та вказуєте шлях до вашого Bicep-файлу. Це спосіб через командний рядок, але є також і керований процес. У VS Code клацніть правою кнопкою миші на Bicep-файл і виберіть Deploy Bicep-файл. Він проведе вас через весь процес. Вас попросять назвати розгортання, обрати підписку, створити або вибрати групу ресурсів, а також запитають про файл параметрів. Ви відповідаєте «Ні» і розгортання починається. Результат з'явиться на вашому порталі Azure. Це те саме, що клацати на порталі, але тепер у вас є файл, який можна використовувати повторно. Ви можете зафіксувати його у своєму репозиторії, поділитися з командою та запустити знову завтра.

А ось і магія. Запустіть те саме розгортання знову і подивіться, що станеться.

Це саме те, що дає вам ідемпотентність. Першого разу ви запускаєте байсеп-файл, і він створює групу ресурсів, але вдруге нічого не відбувається. Жодних помилок, жодних дублікатів, нічого. Байсеп перевіряє, що вже є вежур, порівнює з вашим запитом і каже, що змінювати нічого. Він не намагався створити нову групу ресурсів і не видав помилку про те, що вона вже існує. Він просто підтвердив, що поточний стан відповідає бажаному. Уявіть це як виконання GitStatus у чистому репозиторії. Там нічого робити. Все вже саме так, як має бути. Це і є сила інфраструктури як коду. Ви можете запускати розгортання знову і знову і щоразу отримувати той самий результат. Жодних сюрпризів, жодного суву конфігурації. Ви точно знаєте, що розгорнуто, бо так написано у файлі. Файл стає вашим єдиним джерелом істини. Вам більше не треба думати, чи не забули ви налаштування, стикатися з проблемою, на моєму комп'ютері працює, або шукати в порталі Azure, чи хтось щось змінив.

Файл каже вам, що там є. Якщо хочете щось змінити, ви змінюєте файл і розгортаєте знову. Якщо хочете перевірити, запустіть розгортання ще раз, і воно підтвердить, що все збігається. Ось як ви будуєте впевненість у своїй інфраструктурі. Файл – це джерело істини. Не ваша пам'ять, не документ Word, не відео на YouTube піврічної давнини, а файл. Отже, DeBicep вписується в загальну картину Azure. Загальна картина, де DeBicep займає своє місце. DeBicep живе всередині екосистеми Azure Razos Manager. Це не окремий інструмент. Багато хто так думає, але насправді це просто кращий спосіб писати ERM-шаблони. Технічно це все ще ERM, той самий механізм розгортання, той самий ARRI – все те саме. Єдина різниця – це спосіб написання. І оскільки Bicep компілюється в ERM, усе, що працює з ERM, працює із Bicep. Azure Policy забезпечує відповідність ваших розгортань вимогам. RBAC контролює, хто і що може розгортати.

Cost Management відстежує витрати на ваші ресурси. Azure DevOps та GitHub Actions розгортають ваші Bicep-файли через конвейери. Все працює ідеально, оскільки Bicep створює стандартний JSON для ERM. Ви нічого не втрачаєте, переходячи на нього. Насправді, ви отримуєте ясність. Microsoft побудувала цілу екосистему навколо Bicep. Azure Verified Modules або AVM – це підібрана бібліотека модулів Bicep та Terraform, що відповідають найкращим практикам. Вам не потрібно писати все з нуля. Ви можете використовувати готові модулі для типових завдань, як-от віртуальні мережі, облікові записи зберігання та служби додатків. Вони протестувані, підтримуються та узгоджені з концепцією Well-Architected Framework. Cloud Adoption Framework містить еталенні реалізації Bicep для стандартизованих корпоративних архітектур. Якщо ви створюєте цільову зону Landing Zone, для цього є шаблон Bicep. Стеки розгортання забезпечують керування життєвим циклом для груп ресурсів.

Ви можете розгорнути стек, і якщо видалите ресурс із файлу Bicep, стек може видалити його за вас. Або захистити його від випадкового видалення. Вирішувати вам. Екосистема продовжує зростати завдяки новим модулям, кращим інструментам та глибшій інтеграції зі штучним інтелектом і Дітхаб Коупайлот. Ви можете описати бажаний результат простою мовою, а Коупайлот згенерує для вас код Bicep. Майкрософт продовжує інвестувати в Bicep як основний інструмент для роботи з ажур. Тож нові функції впроваджуються насамперед у Bicep. Шаблони ERM все ще працюють, але інновації відбуваються саме в Bicep. Отже, головний висновок. Якщо ви працюєте вежур, Bicep – це природний наступний крок після клікання в порталі. Вам не потрібно вивчати Терафом або опановувати ERM.JS.ОН. Ви встановлюєте дві речі, пишете кілька рядків коду і розгортаєте інфраструктуру, яка є відтворюваною, версійною та надійною. Дозвольте залишити вас із чимось практичним, що ви можете зробити вже сьогодні.

Отже, тепер ви знаєте, що таке інфраструктура як код, навіщо потрібен Bicep і як він спрощує розгортання вежур. Ось головна думка. Bicep – це не окрема система розгортання. Це кращий спосіб написання тих самих шаблонів ERM, використовуючи той самий механізм і Azure Razos менеджа, але мовою, яку люди можуть читати і писати. Ось завдання для вас. Створіть файл мейн Bicep, розгорніть групу ресурсів і запустіть розгортання двічі. Подивіться, як це працює обидва рази. Першого разу він створює ресурс, а другого – підтверджує, що нічого не змінилося. Це той самий момент усвідомлення, коли ви розумієте, що більше ніколи не повернетеся до клікання в порталі. Це основа. Звідси ви можете додавати облікові записи зберігання, віртуальні мережі та служби додатків за тим самим шаблоном. Напишіть файл, розгорніть його, запустіть знову. Цей файл стає вашим джерелом істини, а все інше випливає з нього. Якщо це було корисно, поділіться з тими, хто все ще клікає в порталі.

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