Azure

Що це таке

Azure, повністю Microsoft Azure, — це каталог обчислювальних ресурсів, які Microsoft здає в оренду зі своїх дата-центрів: віртуальні машини, облікові записи сховища, керовані бази даних, хостинг контейнерів, приватні мережі та інструменти для керування всім цим, з оплатою за використання. До квітня 2014 року Microsoft продавала його під назвою Windows Azure, а тоді дала йому теперішню назву.

Кожен запит до Azure, чи то клацання на порталі, команда в Azure CLI або PowerShell, виклик із SDK чи шаблон, приходить до тих самих дверей: Azure Resource Manager. Він автентифікує запит, перевіряє права і передає його сервісу, який виконує роботу. Віртуальна машина, сервер бази даних і зона DNS — усе це ресурси в його розумінні, кожен з ідентифікатором, типом і набором властивостей.

Ресурси впорядковано в ієрархію з чотирьох рівнів. Кожен ресурс належить рівно до однієї групи ресурсів (resource group) — теки для того, що розгортають, оновлюють і видаляють разом; видалення групи видаляє все, що в ній. Групи ресурсів лежать у підписці (subscription), яка водночас є одиницею оплати й межею для доступу та лімітів. Підписки збирають у групи керування (management groups), які можна вкладати до шести рівнів і які всі сходяться до однієї кореневої групи каталогу. Призначення ролей, політики й бюджети, задані на одному рівні, діють на все, що нижче.

Над усією ієрархією стоїть ідентичність. Користувачі, групи й застосунки організації живуть у тенанті Microsoft Entra ID — каталозі, який до 2023 року називався Azure Active Directory, — і кожна підписка Azure довіряє рівно одному такому тенанту, що автентифікує людей і вирішує, що їм дозволено.

Чому це важливо

Більшість команд, що працюють в Azure, прийшли туди через те, що вже мали. Компанія, чиї співробітники входять у Microsoft 365, уже тримає своїх людей у тенанті Entra, і підписка, яка довіряє цьому тенанту, може дати тим самим обліковим записам доступ до серверів і баз даних без другого каталогу користувачів, який треба підтримувати. Для підрядника вибір Azure тому залежить не так від таблиць можливостей, як від того, де вже лежать ідентичності й дані клієнта.

Друга причина — ієрархія, бо в ній живе керування. Настанови Microsoft щодо впорядкування ресурсів радять окремі підписки для розробки, тестування і продакшну, щоб середовища не обростали залежностями одне від одного і кожне мало власні політики та власний рядок у рахунку. Azure Policy потім застосовує внутрішні правила на тому рівні, де її призначено. Вона може заборонити зміну, наприклад ресурс, створений у регіоні, яким організація не користується, або записати її в журнал для перегляду, і Microsoft радить запускати нову політику в режимі аудиту, перш ніж дозволяти їй щось блокувати.

Третя причина — Azure можна описати, а не наклацати. Resource Manager приймає декларативні шаблони, написані в JSON або Bicep, і сам визначає, що створити чи змінити. Повторний запуск того самого шаблону дає той самий результат, а стан розгорнутого Azure зберігає сам, тож окремий файл стану доглядати не треба. Середовище, записане так, можна переглянути як pull request, відбудувати після поганого дня і скопіювати в нове середовище, змінивши параметри. Це головний захист від налаштування Azure, яке розуміє лише одна людина.

Як це виглядає на практиці

Сторінка технологічного стека називає Google Cloud і AWS звичними хмарами компанії, а Azure — там, де клієнт уже в ньому працює. Два проєкти в портфоліо показують роботу з Azure з двох боків.

З боку інфраструктури три середовища Azure записали як код, усі з тих самих шаблонів Bicep: api та www працюють як Azure Container Apps у managed environment, поруч PostgreSQL Flexible Server, Redis для кешування, Front Door з політикою WAF попереду, а під ними VNet, NSG і приватний DNS, з підключеним Log Analytics для діагностики та образами з Azure Container Registry проєкту. Оскільки шаблони параметризовано, нове середовище чи зміна наявного — це pull request, а дрейф перестав бути загадкою, бо джерелом істини є код.

З боку релізів розгортання в Azure взяли під контроль від початку до кінця. Релізи рухаються фіксованим маршрутом, спочатку development, потім staging, потім production, і ніхто не пушить напряму в live-середовище. Пайплайн CI/CD збирає й постачає образи, а шаблони Bicep тримають цільову інфраструктуру ідентичною від одного середовища до іншого. Конфігурація, що відрізняється для кожного середовища, зберігається окремо від секретів, тож той самий зібраний артефакт проходить через усі середовища й підхоплює правильні налаштування там, де опиняється, без жодних ситуативних ручних розгортань.

Де виникають проблеми

Дорогі помилки в Azure зазвичай мають одну форму: розрив між тим, що, на чиюсь думку, Azure зробив чи дозволив, і тим, що Resource Manager зробив насправді.

Розгортання шаблону дещо лишає і дещо повертає. За замовчуванням Resource Manager розгортає в інкрементному режимі. У цьому режимі ресурс, який є в групі ресурсів, але відсутній у шаблоні, лишається на місці, тож якщо прибрати базу даних із файлу шаблону, сервер і далі працює й нараховує плату. Той самий режим повторно застосовує кожну властивість кожного ресурсу, який розгортає знову, а властивість, пропущена в шаблоні, повертається до значення за замовчуванням. Налаштування, яке хтось змінив на порталі, тому перезаписується під час наступного звичайного релізу. Попередній перегляд what-if може попередити про обидва випадки, але Microsoft зазначає, що його вивід може містити шум — хибні спрацювання, серед яких справжню зміну легко пропустити. Шаблон має явно задавати кожне значення, що відрізняється від типового, а deployment stack, який від’єднує або видаляє ресурси, що випали з шаблону, дає раду залишкам.

Усі середовища ділять одну підписку. Так найшвидше почати: одна підписка, група ресурсів на кожне середовище і широкі ролі, видані на верхньому рівні, щоб нікого не блокувати. Тоді продакшн і тест ділять призначення ролей, політики, ліміти й один рахунок, а скрипт, спрямований на тестову групу, працює з правами, які дістають і до продакшну. Окремі підписки під групою керування дають кожному середовищу власний доступ, власні правила й власні витрати.

Адміністратора каталогу вважають адміністратором ресурсів. Ролі Microsoft Entra, як-от Global Administrator, керують каталогом: користувачами, групами, паролями й доменами. Ролі Azure, як-от Owner і Contributor, керують ресурсами. За замовчуванням жоден із цих наборів не сягає в інший. Global Administrator може ввімкнути перемикач, який надає йому роль User Access Administrator на кореневому рівні, а з нею змогу бачити всі ресурси й призначати доступ у будь-якій підписці тенанта. Перемикач існує, щоб відновити доступ до підписки, і Microsoft радить прибрати підвищений доступ, щойно роботу завершено. Якщо його лишити, виходить обліковий запис каталогу, який може видати собі доступ до будь-якого ресурсу.

Застосунок-контейнер, що ніколи не спить. Azure Container Apps може масштабувати більшість застосунків до нуля реплік, коли їх ніхто не викликає, і це частина його привабливості для невеликих сервісів. Застосунки, що масштабуються за навантаженням на процесор чи пам’ять, — виняток: до нуля вони не масштабуються. Застосунок із правилом за процесором тримає щонайменше одну репліку ввімкненою кожної тихої ночі, тож сервіс, обраний за те, що без запитів він майже нічого не коштує, варто масштабувати за HTTP-трафіком або іншим джерелом подій.

Що почитати далі

• Azure documentation — покажчик посібників, швидких стартів і довідників Microsoft для кожного сервісу Azure.
• What is Azure Resource Manager? — шар, через який проходить кожен запит, і як розмежовувати групи ресурсів.
• Organize your Azure resources — Cloud Adoption Framework про групи керування, підписки та групи ресурсів.
• Deployment modes — що інкрементний режим лишає працювати і які властивості скидає повторне розгортання.
• Deployment stacks — як керувати ресурсами шаблону як однією одиницею, зокрема тими, що з нього прибрали.
• Azure roles and Microsoft Entra roles — де закінчуються ролі каталогу, де починаються ролі ресурсів і як підвищений доступ їх поєднує.